Few technical debates generate more heat and less light than microservices versus monolith. Experienced architects can make confident, opposing cases while citing the same companies as evidence.
Amazon, Netflix, and Uber are microservices success stories. They are also examples of organisations that operated highly successful monolithic systems for years before decomposing them, and that had very specific scale, team, and operational characteristics that made decomposition the right call at the right time.
The debate is almost always framed incorrectly. The question is not which architecture is better. It is which architecture is right for this organisation, at this stage of growth, with this team structure and this operational capability.
The case for starting with a monolith
If you are building a new product, an MVP, an early-stage platform, or a new business line, a well-structured monolith is almost always the right starting point.
- Faster initial developmentA single deployable unit removes inter-service communication overhead and lets the team focus on product instead of platform complexity.
- Easier debuggingWhen something goes wrong, you have one call stack and one log stream rather than a distributed tracing problem spread across multiple services.
- Lower operational complexityMicroservices multiply deployment pipelines, infrastructure, SLOs, and operational overhead long before many teams are large enough to benefit from that complexity.
When microservices make sense
Microservices become the right answer when specific organisational and technical conditions are in place, not before.
- Team scaleMicroservices work best when multiple independent teams need to own and deploy services without constant coordination across the whole system.
- Independent scaling requirementsWhen one component needs to scale dramatically beyond the rest, decomposition can let you scale it without scaling everything.
- Different deployment cadencesIf different domains genuinely need to ship independently and frequently, a monolith may start creating bottlenecks.
The architecture we actually recommend
For most early-stage and growth-stage companies, our recommendation is a modular monolith: a single deployable unit with clean internal module boundaries, well-defined interfaces between domains, and a structure that makes future decomposition tractable when the conditions that justify it actually arrive.
A modular monolith gives you the development velocity of a monolith now with the architectural clarity that makes a future migration to microservices a planned evolution rather than a painful emergency.
The worst outcome we see regularly is a premature microservices decision made for the wrong reasons, usually because it looked more sophisticated or felt inevitable. The result is a distributed monolith: all the complexity of microservices, none of the benefit, and a team spending more time managing infrastructure than building product.
Choose your architecture for where you are. Build it so it can evolve to where you are going. That is the principle that holds across almost every context we work in.