The microservices vs monolith debate has been running for a decade. In 2026, the conversation has matured: the initial “microservices always” orthodoxy has been revised, and the question now is more nuanced. Here is where things actually stand.
The Case That Was Made for Microservices
The arguments for microservices that drove adoption in 2015–2020: independent deployment (each service can be deployed without coordination); independent scaling (scale only the services that need it); technology freedom (each service can use a different programming language or database); team autonomy (teams can own and operate their services independently, reducing coordination overhead); fault isolation (a failure in one service doesn’t necessarily bring down everything). These are real benefits. At Netflix, Amazon, and Google scale — where you have hundreds of engineers, many teams, and services with wildly different scaling requirements — microservices made and continue to make sense.
What Went Wrong with the Pattern
The microservices hype led many organisations to adopt the pattern before they were at the scale where its benefits materialise. The costs that were underestimated: distributed systems complexity (network calls fail, latency compounds, you now need distributed tracing, service meshes, and circuit breakers); operational overhead (each service needs its own CI/CD pipeline, monitoring, logging, alerting, on-call rotation); the distributed data problem (transactions that were trivial in a monolith require saga patterns or two-phase commit in microservices — extremely complex); network latency (a function call in a monolith takes microseconds; a network call takes milliseconds — at 10–50 service hops per request, this compounds); testing complexity (integration testing across 20 services is much harder than testing a monolith). Sam Newman (author of Building Microservices) and Martin Fowler have both written extensively about organisations adopting microservices too early and paying a high price in complexity.
The 2026 Realistic View
The honest position: start with a modular monolith. A well-structured monolith with clear internal module boundaries is not the same as a “big ball of mud” monolith. A modular monolith can be: deployed quickly as a single unit; tested easily; operated by a small team without distributed systems expertise; and extracted into services later if you reach the scale where that makes sense. The migration path: extract services when you have a clear reason — a specific service that needs to scale independently, a team boundary that’s being crossed repeatedly, or a part of the system that would benefit from a different technology. Don’t extract services pre-emptively. The “monolith is bad” reputation: often comes from conflating modular monoliths with poorly structured code. A monolith with clean architecture (clear domain boundaries, dependency inversion, good test coverage) is a reasonable foundation for many companies that will never reach microservices-appropriate scale. The current consensus (2026): microservices are appropriate at large organisations with many teams and high-scale services. For startups and small teams, start with a modular monolith and extract when you have evidence that you need to. The “majestic monolith” (David Heinemeier Hansson’s term) has had a rehabilitation.
