Microservices are not a performance optimization pattern.
They are an architectural trade.
When you split a monolith into networked services, you add:
- serialization and deserialization
- network hops
- retry logic
- observability overhead
- more failure modes
That is real cost. Pretending otherwise is not serious architecture.
Why Teams Still Choose Them
The upside is usually elsewhere:
- team autonomy
- separate deployment cadence
- stronger service ownership
- scaling different workloads independently
So the right framing is not "microservices are good" or "monoliths are good."
It is:
"What problem are we paying this tax to solve?"
When the Monolith Is Better
A modular monolith is often the right choice when:
- the team is still small
- the domain boundaries are still changing
- latency between components matters
- operational simplicity is valuable
That is not a compromise architecture. It is often the mature choice.
When Microservices Start Making Sense
The trade becomes easier to justify when:
- the organization is large enough to need stronger boundaries
- parts of the system truly need different scaling profiles
- independent failure domains are valuable
- the team can support the operational complexity
Microservices can be the right answer. They are just rarely the faster answer in raw request-path terms.
Further Reading