For a decade, microservices were treated as the default destination for any serious system, and stepping back from them felt like an admission of failure. That mood has shifted. A growing number of engineering organisations are concluding that the operational tax of fine-grained services outweighed the benefits for their context, and are reconsidering the modular monolith. For leadership, the task is to make this call objectively rather than swinging from one fashion to the next.
What problem were microservices meant to solve
Microservices earn their keep when they solve real problems: independent deployment of components owned by different teams, independent scaling of parts of a system with very different load profiles, and fault isolation so that one failing component does not take down everything. If your organisation has many teams that genuinely need to ship independently, or a system with components whose scaling needs differ by orders of magnitude, the architecture pays for itself.
The trouble is that many organisations adopted microservices without those problems. They split a single team's codebase into a dozen services, and inherited all the cost of distribution, network calls, eventual consistency, distributed tracing and deployment orchestration, while gaining little of the benefit. The architecture solved a coordination problem they did not have, and created an operational one they now do.
The hidden costs of distribution
Every time a function call becomes a network call, you take on a set of problems that simply do not exist in a single process. Calls can fail partway, latency accumulates, and data that was once trivially consistent now requires careful coordination across services. Debugging a request that touches eight services demands distributed tracing and correlated logs just to answer questions a stack trace would have answered for free. Local development becomes harder because reproducing the system means running many services at once.
None of this is insurmountable, and mature organisations manage it well. But it is a real and ongoing cost, paid by every engineer every day. The honest question is whether your organisation is receiving value commensurate with that cost. For many, the answer on reflection is no.
What a modular monolith actually is
A modular monolith is not a return to the tangled big ball of mud. It is a single deployable application with strong internal boundaries: well-defined modules with explicit interfaces, clear ownership and enforced separation, so that one module cannot reach into another's internals. The discipline that microservices impose through network boundaries is instead imposed through code structure, dependency rules and architectural tests.
The payoff is that you keep the modularity and clear ownership that good design requires, while avoiding the distribution tax. Calls are in-process and fast. Transactions are straightforward. Deployment is one artefact. Crucially, a well-modularised monolith preserves the option to extract a module into its own service later, if and when a genuine need arises, because the boundaries are already in place.
- List the specific problems your current architecture is meant to solve, and check honestly whether you actually have them.
- Measure the operational cost you are paying: deployment complexity, debugging time, infrastructure spend and onboarding friction.
- Assess whether your team structure genuinely requires independent deployment, or whether one team owns most services.
- Enforce module boundaries in code with dependency rules and architectural tests, not just good intentions.
- Identify the few components, if any, that have a real case for independent scaling or fault isolation.
- Plan any consolidation as an incremental migration with clear checkpoints, not a risky big-bang rewrite.
Making the call objectively
Resist deciding by sentiment in either direction. Gather evidence. How long does a typical change take to ship, and how much of that time is spent on coordination across services. How much of your infrastructure spend and operational toil exists purely to run the distributed topology. How often does fault isolation actually save you, versus how often a cascading failure crosses service boundaries anyway. How many teams truly deploy independently, and how many simply deploy on the same schedule despite the separation.
Set these costs against the benefits you genuinely realise. If the benefits are real and substantial, keep the architecture and invest in operating it well. If they are mostly theoretical, a modular monolith may serve you better. The point is to decide from data about your own system, not from what worked for a famous technology company with very different constraints.
A pragmatic middle path
The decision is rarely all or nothing. Many organisations land on a sensible middle ground: a modular monolith for the core of the system, with a small number of services carved out where independent scaling or isolation genuinely matters. A high-volume, computationally heavy component might warrant its own service while the rest of the application stays consolidated. This selective approach gives you the benefits of distribution exactly where they apply, and avoids paying for them everywhere else.
If you do consolidate, treat it as an incremental migration. Merge services in stages, validate at each step, and keep the modular boundaries intact so the work strengthens the design rather than blurring it. A big-bang rewrite carries risk out of all proportion to the benefit.
Common pitfalls
The biggest pitfall is treating the architecture choice as an identity rather than an engineering trade-off, so the decision is driven by fashion or pride. A second is collapsing services back together without preserving internal modularity, which simply recreates the big ball of mud everyone feared. A third is ignoring team structure: an architecture that does not match how your teams are organised will fight you regardless of its technical merits. Finally, beware the assumption that you must choose one model for the whole system, when a selective hybrid often fits best.
What good looks like
A good outcome is a system whose architecture matches the problems it actually has and the way its teams actually work. Changes ship quickly, the cognitive load on engineers is manageable, and the operational cost is justified by genuine benefit. The boundaries are clear and enforced, so the design stays healthy and keeps its options open. Whether that lands on a modular monolith, a set of services or a deliberate hybrid is secondary to the discipline of having chosen on evidence.
Reassessing your architecture with clear eyes can recover significant engineering capacity and reduce risk. Need support applying this approach? Email sales@halfteck.com.