Modular monoliths are replacing microservices for mid-size engineering teams
For most of the last decade, breaking an application into microservices was treated as the responsible thing to do — the thing you did once you were serious about scale. In 2026, a growing number of engineering teams are quietly reversing that decision, not by giving up on service boundaries, but by collapsing them back into a single deployable unit with strict internal module separation: the modular monolith.
The clearest public example remains Amazon's Prime Video team, which in 2023 moved its video quality analysis service from a distributed, Lambda-and-microservices pipeline into a single monolithic process. The team reported a roughly 90% reduction in infrastructure cost for that specific service, along with far simpler debugging — no more stitching together logs across a dozen services to trace one request. That case study has become the reference point engineers cite when making the argument internally, even though it describes one service, not a wholesale architectural reversal.
Why the pendulum swung back
Microservices solve a specific problem: independent deployability and independent scaling for teams large enough that a shared codebase becomes a coordination bottleneck. For a 200-person engineering org split into dozens of autonomous teams, that trade-off makes sense. For a 15-person team running 40 microservices — a pattern that became disturbingly common during the last decade’s scaling hype — the operational overhead swallows the supposed benefit. Every service needs its own CI pipeline, its own on-call rotation, its own retry and circuit-breaker logic, its own versioned API contract with every other service that talks to it. Distributed tracing becomes mandatory just to answer basic debugging questions a monolith answers with a stack trace.
Basecamp and Shopify have both publicly described staying with, or returning to, a "majestic monolith" model rather than splitting into dozens of services, citing the same reasoning: most of their request paths don’t need independent scaling, and a single well-organized codebase lets any engineer understand the whole system’s behavior instead of needing a map of forty repositories.
What a modular monolith actually looks like
A modular monolith is not “giving up and writing spaghetti code in one file.” It’s a single deployable application internally organized into packages or modules with explicit, enforced boundaries — typically one module per business domain (billing, inventory, notifications). Each module owns its own data access layer and exposes a narrow internal interface to other modules. The discipline that microservices enforce through network boundaries, a modular monolith enforces through compiler or linter rules: a billing module literally cannot reach into inventory’s database tables, because the build fails if it tries.
This gets you most of the benefits people originally wanted from microservices — clear ownership, limited blast radius for changes, the ability to reason about one domain at a time — without the distributed-systems tax: no network latency between modules, no partial-failure handling for calls that used to be function calls, one deployment pipeline, one place to look at logs.
When microservices still earn their cost
The honest case for microservices still exists. If a single component needs to scale independently by 50x relative to the rest of the system (a recommendation engine during a flash sale, for instance), splitting it out is the right call. If different parts of the system genuinely need different languages or runtimes — a Python ML inference service sitting next to a Go-based transaction processor — that’s also a legitimate reason. And if the organization is large enough that dozens of teams would otherwise be blocked on each other’s deploys in a shared codebase, the coordination cost of a monolith can exceed the coordination cost of services.
The practical rule that’s emerged among teams making this call in 2026: default to a modular monolith, and extract a service only when you can name the specific scaling, language, or team-autonomy requirement that justifies it — not because an architecture diagram looks more sophisticated with more boxes on it.
Takeaways for teams reconsidering their architecture
If your team is under roughly 50 engineers and running more than a handful of services, audit which services actually have independent scaling needs versus which were split for organizational reasons that no longer apply. Start by merging the services with the lowest traffic and the most coupled data models — those are costing you the most in operational overhead relative to the isolation benefit they provide. Keep the module boundaries; drop the network hops.