How Much Slower Are Microservices Than a Monolith? The Benchmark Numbers That Surprised Engineers

Wotech

Author at Wotech Electronics Blog

Microservices are hailed as the "modern" architecture, but have you ever wondered: in exchange for that flexibility, how much performance does the system pay? An experiment just conducted has produced concrete numbers — and they are bigger than many people imagine.

The debate between Monolith and Microservices has never stopped in engineering circles. Everyone knows the theory: moving to Microservices means trading away some performance in exchange for flexibility in scaling the team. But how much is "some"? 5%? 10%? In reality, very few tests have measured the numbers closely. This article summarizes a detailed, objective experiment conducted by engineer Arjay McCandless (a former Microservices and Serverless architecture engineer at Amazon), shared and analyzed by Lữ Minh Khương in the VGU Tech Alumni group.

The shocking result in one paragraph

When a Monolith application running on an 8 vCPU server (16GB RAM) is split into 4 Microservices running on 4 servers of 2 vCPU each (4GB RAM per machine) — with the same total hardware budget of $112/month — the system's maximum capacity:

• Drops from 60,000 users (about 15,400 requests/second) to 18,000 users with HTTP/JSON

• Reaches 19,000 users with gRPC

• Even with optimized resource allocation (rebalancing replicas) and gRPC, the best Microservices configuration only reaches 30,000 users — a 50% performance drop compared with the Monolith on one large server, and 40% lower than a horizontally replicated Monolith on 4 small servers (50,000 users)

The core cause: the CPU cost of encoding/decoding data, managing network connections, and having to replace direct SQL JOIN statements with chains of API calls back and forth between services.

The testing methodology: fair down to every detail

To make the test fair, the author used Conduit — a Medium-like blogging platform from the RealWorld benchmark suite. Users can post articles, follow each other, load the feed, favorite articles, comment, and manage profiles.

Both versions were written in Go with the standard HTTP library:

• Monolith: the entire application runs in a single process.

• Microservices: split into 4 independent services — Users, Profiles, Articles, Comments.

As for the database, each service owns its own tables: Users manages user information, Profiles manages follow relationships, Articles manages posts/tags/favorites, and Comments manages comments. All 4 services share one PostgreSQL cluster of 16 vCPU, but each service connects through its own database role and accesses only its own tables — following the data ownership principle of Microservices.

This is exactly what completely changes how data is retrieved: in the Monolith, fetching an article along with its author's name requires just one SQL JOIN. In Microservices, the Articles service cannot directly JOIN the tables of Users or Profiles — it must make API calls to the corresponding services.

Thoroughly optimized before measuring

So no one could blame "naive design," the Microservices version was carefully optimized:

• Internal APIs support batching by list of IDs — avoiding the classic N+1 calls problem

• Connection pooling reused across requests

• Token validation handled locally, with no request back to an Auth service

• Services communicating over the internal network of the same data center (New York), eliminating cross-region latency

• No API proxy or Service Mesh — no intermediate layer adding overhead

• Every configuration had to pass 197 conformance checks before measurement

Hardware configuration and scoring criteria

The Application Server tier budget was fixed at $112/month on DigitalOcean (the actual total cost for the entire database cluster and load generators exceeded $1,500/month). At this budget level, there are 2 equivalent options:

In front sits Nginx running on a separate 8 vCPU server; load is fired from 3 independent load generator machines. Every 1,000 virtual users generate about 250–270 requests/second with a mixed workload: browsing posts, opening profiles, viewing comments, and occasionally posting content.

The score for each configuration = the maximum number of users the system can sustain continuously for 5 minutes while still meeting the SLA:

• 95% of requests (p95) respond in under 500ms

• 99% of requests (p99) respond in under 1 second

• Error rate below 1%

The experimental results, stage by stage

Stage 1: Establishing the baseline with the Monolith

Running the Monolith on the large 8 vCPU/16GB server: the system handles 60,000 users (~15,400 req/s).

Next, the author horizontally scaled the Monolith: 4 identical replicas on 4 servers of 2 vCPU, with Nginx load balancing. Result: 50,000 users — about 17% lower than one large machine, due to separate operating system overhead on each machine, network overhead, and the non-uniformity of virtualized hardware.

So the Monolith's baseline: 60,000 users (1 large server) and 50,000 users (4 small servers).

Stage 2: Splitting into 4 services but still on the same 8 vCPU machine

To isolate the hardware variable and measure only the pure cost of the software architecture, all 4 services ran as 4 separate processes on the same 8 vCPU machine.

• HTTP/JSON: capacity fell from 60,000 to 25,000 users

• gRPC (Protocol Buffers): reached 29,000 users

Most notable was the CPU figure: per public request, the Monolith consumed only 0.47ms of CPU, while Microservices over HTTP consumed up to 1.2ms of CPU — more than 2.5 times the CPU workload, even with everything on the same machine and not passing through any physical network cable.

The reason: in-process function calls now become calls over the internal network between processes. To return one article, the Articles service calls the Profiles service, and Profiles calls the Users service in turn — each step costs client code, server code, connection management, JSON encode/decode, and OS scheduling.

Stage 3: Deploying the 4 services on 4 separate servers

This is the model closest to a real deployment — one 2 vCPU machine per service.

• HTTP/JSON: only sustained 18,000 users

• gRPC: sustained 19,000 users

Placed next to the 50,000 users of the Monolith replicated on exactly these 4 machines, the drop is enormous.

When checking CPU utilization to find the bottleneck, the author discovered a serious load imbalance: the machine running Articles was pushed to 95% CPU, while the Comments machine only used up to 52%. The "one machine per service" split falsely assumes that every service needs equal resources — when in reality article-reading traffic is far heavier than comments. The spare CPU on the Comments machine cannot be "transferred" to help Articles.

Stage 4: Optimizing resource allocation (Rebalancing)

Leveraging Microservices' advantage of independent scaling without increasing the budget (still 4 machines of 2 vCPU), the author deployed a second replica of the Articles service on the machine running Comments and adjusted the traffic distribution ratios:

• HTTP/JSON: rose slightly from 18,000 to 20,000 users (1.27ms CPU/request)

• gRPC: jumped from 19,000 to 30,000 users (0.91ms CPU/request — a ~58% improvement over pre-balancing, and 28% lower CPU cost than HTTP)

30,000 users on 4 small servers approaches the result of Microservices on 1 large server (29,000), but is still 40% lower than the Monolith on 4 small servers (50,000) and 50% lower than the Monolith on 1 large server (60,000).

Results summary table

Can Serverless and auto-scaling save it?

Many people think of Serverless (AWS API Gateway + Lambda + DynamoDB) or auto-scaled containers to self-compensate for the missing compute. But the experimental data shows: automatic resource provisioning does not make the overhead costs disappear. To serve 15,000 public requests/second (the load the Monolith could handle):

In other words: whether you have Serverless or auto-scaling, you still pay for 2 to nearly 3 times the compute to handle the same traffic.

So why do Amazon, Netflix, and Facebook still choose Microservices?

The answer doesn't lie in server performance, but in organizational and human scaling.

When you have hundreds of engineers divided into teams responsible for Search, Billing, Recommendation, etc., clear service boundaries allow each team to independently build, test, deploy, and roll back — without waiting for a shared release cycle. Each team can also choose the language/framework best suited to its problem. For a large organization, the speed of feature development and team autonomy fully justify the added infrastructure cost.

Two traps many projects fall into

• False independence (Distributed Monolith): many systems split into Microservices, yet every new feature launch requires 4 teams to coordinate changes to APIs simultaneously, deploy in exactly the right order, and manage complex versioning. The result: you lose the Monolith's performance without gaining Microservices' independence — losing both worlds.

• The illusion of failure isolation (Blast radius isolation): the theory that one service failing doesn't bring down the whole system. But without fault-tolerant design (fault tolerance, graceful degradation), a crash in a core service like Users still takes down every feature of the services that depend on it.

A perspective for Vietnamese businesses

For most small and medium-sized businesses in Vietnam — engineering teams of a few dozen people, limited infrastructure budgets — the lesson is quite clear:

• Don't split into Microservices just because it's "the era." If your system hasn't hit a ceiling that one powerful server (or a few Monolith replicas behind a load balancer) can't handle, the Monolith is almost always the more cost-effective choice.

• If you have already split: pay attention to balancing resources according to actual traffic (don't assign one machine per service equally), prefer gRPC for internal communication, and use batching and caching sensibly.

• The Modular Monolith — dividing modules and clear code boundaries inside a single application — may well return as the default choice for most new projects, especially as AI tools help small teams accomplish the workload of large ones, keeping operations simple and avoiding all the unnecessary internal communication overhead.

Every architecture has its price. What matters is knowing exactly what you're paying for — and the experiment above shows that price can be measured precisely down to each millisecond of CPU.

Conclusion

Microservices aren't "bad" — they are a tool for solving an organizational problem, not a performance problem. If your goal is to optimize infrastructure costs for a fixed amount of traffic, the Monolith (single or horizontally replicated) wins decisively: for the same $112/month, you get double the capacity. If the goal is to let many teams develop in parallel and independently at the scale of hundreds of engineers — Microservices are worth every penny of the premium.

Which architecture are you running your system on? Have you ever struggled to optimize latency and infrastructure costs after splitting into Microservices? Share your experience in the comments.

References

• Original experiment: Arjay McCandless — "How much slower are Microservices? (I tested)"

• Vietnamese analysis: Lữ Minh Khương — VGU Tech Alumni group

• Application benchmark suite: RealWorld (Conduit)