The Modular Monolith Comeback
A modular monolith is a single deployable application organised into strict internal modules with clean boundaries — domain-driven design without the operational tax of microservices. In 2026, this is the right default for teams under 50 engineers, products under 12 bounded contexts and traffic under ~10K requests/second. It gives you 80% of the architectural benefits microservices promise (clean boundaries, replaceable modules, testability) at 20% of the operational cost (one deploy pipeline, one observability story, one database to back up). Most teams that adopted microservices between 2018 and 2022 are now spending 30–60% of their engineering capacity on platform overhead — distributed tracing, service mesh, deploy orchestration — that delivered no measurable business return.
When Microservices Earn Their Complexity
Microservices genuinely pay off above three concurrent thresholds: 50+ engineers organised into independent teams (Conway's Law — service boundaries should mirror team boundaries), 12+ bounded contexts with distinct scaling and compliance needs, and 10K+ requests/second where horizontal scaling of specific hot paths matters more than overall throughput. Below those thresholds, the operational cost — platform team, service mesh, distributed tracing, deploy orchestration, eventual-consistency handling — typically exceeds the agility benefits. The exception is regulated workloads (HIPAA, PCI, RBI) where blast-radius isolation is itself a compliance benefit.
The Three Failure Modes of Premature Microservices
Distributed monolith — services that share a database or are deployed together — gives you all the operational pain of microservices with none of the independence benefits. Network coupling — synchronous service-to-service calls forming chains 4+ deep — turns every release into a coordination meeting and every outage into a cross-service investigation. Premature optimisation — splitting modules that haven't yet proven distinct scaling, deployment or team-ownership needs — locks in boundaries that almost always turn out to be wrong, and 'merging' microservices back into a monolith is harder than splitting one apart. The right path for most teams: start as a strict modular monolith, extract specific services only when concrete pressure justifies it.
