The idea of microservices is attractive: split a large system into smaller services, give each one clear responsibility, and let teams release changes independently.
But with that independence come networks, separate deployments, observability, data consistency, resilience, and many new ways to fail where there used to be one process.
So the question is not whether microservices are good. The question is whether the independence pays for itself.
What problem are we solving?
Microservices are most useful when parts of the product genuinely move at different speeds.
One team owns payments, another catalog, another logistics. They have different change cycles, different load patterns, and different reliability requirements.
If all of them must wait for one release and constantly coordinate changes in one system, architecture starts slowing the organization down.
What does the business get?
The main business benefit is the ability to scale delivery speed with the number of independent teams.
A payments release does not have to wait for catalog changes. A team can fix an issue, run an experiment, or ship a feature in its area without a large coordinated release.
That reduces coordination cost and shortens the path from decision to production.
There is another effect: different parts of the business can scale differently. If one service experiences a sharp increase in load, the whole system does not necessarily have to scale with it.
But this benefit only appears at sufficient organizational scale. For a small team, microservices often do not reduce coordination — they create a new technical layer of it.
What does the team get?
A well-defined service gives a team ownership: clear boundaries, its own release cycle, and less need to coordinate every internal change with neighboring teams.
The team can scale its component appropriately and evolve its implementation independently as long as it preserves the contracts other services depend on.
But autonomy is not automatic. If services depend heavily on each other or share one database as an internal API, the company gets a distributed monolith — microservice complexity without microservice independence.
What does the customer get?
The customer benefits indirectly: changes can ship faster, and a failure in one domain does not necessarily need to take down the whole product.
A recommendation issue, for example, should not have to stop checkout.
But a poorly designed distributed system can do the opposite: add latency, create more partial failures, and make recovery harder.
What do we pay for it?
Microservices require a mature engineering environment.
You need automated delivery, strong observability, configuration management, tracing, API compatibility rules, and a good understanding of distributed failure modes.
There is infrastructure cost and capability cost. Some engineering time inevitably moves away from product work and into supporting this operating model.
There is also an organizational price: service boundaries need to match real ownership boundaries. Otherwise technical separation simply creates more dependencies.
When are microservices unnecessary?
If one team can comfortably own the whole system, releases do not block each other, load scales predictably, and the business is still changing the product model frequently, microservices may be premature.
In that case, a modular monolith can preserve most of the useful structure without paying the distributed-system cost.
Questions to ask before choosing them
- Which teams are actually blocking each other today?
- Do they truly need independent release cycles?
- Which parts of the system need independent scaling?
- Are we ready to pay for distributed operations and infrastructure?
- Do service boundaries match real ownership boundaries?
In the end
Microservices are a way to buy independence with additional complexity.
They become economically sensible when the coordination cost inside a monolith is already higher than the cost of running a distributed architecture. Before that point, “modern” can simply mean expensive premature optimization.