The microservices conversation in engineering has become so one-sided that choosing a monolith feels like admitting defeat. But the best architecture is not the most fashionable one — it is the one that solves your actual problems at your actual scale with your actual team. Here is how to cut through the hype and make the decision on its merits.
The Peer Pressure Problem in Architecture Decisions
Architecture decisions made by peer pressure rather than first principles are among the most expensive mistakes engineering organisations make. When a CTO at a high-growth company publishes a post about how microservices unlocked their scaling, the industry infers that microservices unlock scaling universally. They do not. They solved a specific problem for a specific organisation at a specific scale. Applying that solution without the corresponding problem is how organisations accumulate complexity without benefit.
The Hidden Costs of Microservices
The costs of microservices that rarely appear in conference talks: network latency on every inter-service call, distributed transaction complexity, eventual consistency requirements that surface as race conditions, operational overhead of managing dozens of deployment pipelines, and the cognitive load of debugging failures that span multiple services. These costs exist regardless of whether you get the benefits. In organisations that adopt microservices prematurely, the costs arrive immediately and the benefits never materialise.
Three Scenarios Where a Monolith Is the Better Architecture
A monolith is often the better architecture when the domain is not yet well understood, when the team is smaller than fifteen engineers, or when the deployment frequency is low enough that coordination overhead is manageable. In each of these cases, a well-structured monolith delivers faster iteration, simpler operations, and easier debugging than a premature service decomposition.
The Modular Monolith: The Under-Utilised Middle Ground
The modular monolith is the architectural pattern that the industry consistently overlooks in its enthusiasm for microservices. A monolith with clear internal module boundaries, well-defined interfaces between modules, and independent testability of each module delivers most of the maintainability benefits of microservices with a fraction of the operational complexity. It is also a far better starting point for a future microservices migration than an unstructured monolith, because the module boundaries provide natural service boundary candidates.
How Team Size Determines Whether Microservices Help or Hurt
The relationship between team size and microservices value is not linear but threshold-based. Below a certain team size, microservices create more coordination overhead than they save in deployment independence. Above that threshold, the ability for teams to deploy independently and own their domains fully becomes a genuine productivity multiplier. That threshold is approximately fifteen to twenty engineers for most product contexts — though the right number depends heavily on the domain complexity and the architectural sophistication of the team.
What Switching Later Actually Costs
The argument for premature microservices often invokes the cost of migrating later: it will be harder to decompose a monolith than to start with services. This argument is partially true but systematically overstated. Migrating a well-structured modular monolith to microservices is a manageable engineering programme. Migrating an unstructured monolith is expensive but tractable. Neither is more expensive than two years of operating a prematurely complex distributed system that delivered slow iteration and high operational cost throughout.
Decision Framework: Microservices Readiness Assessment
Before committing to a microservices architecture, engineering leaders should be able to answer: What specific scaling or deployment bottleneck does this solve? Do we have the team size and operational maturity to absorb the overhead? Is our domain model stable enough to draw service boundaries with confidence? Do we have or can we build a platform layer that handles cross-cutting concerns? If the answers are uncertain, the architecture is premature.
Making the Case for Simplicity
The strongest argument for a simpler architecture is not philosophical but economic. Simpler systems are cheaper to operate, faster to iterate on, easier to onboard engineers into, and less risky to change. Complexity is not a virtue. It is a cost that must be justified by proportionate benefit. Engineering leaders who can make this case clearly and defend it against peer pressure are providing genuine value to their organisations.
Related Reading
Evaluating your architecture options and want an independent perspective?
Our architects work with CTOs and engineering leaders to assess architectural decisions on their merits — not on what is fashionable — and design systems that are right for your stage and scale.
Schedule a Consultation