Monoliths vs. Microservices: Why 42% of Teams Are Switching Back

For the better part of a decade, microservices have been the unquestioned default for any engineering team that wanted to be taken seriously. The playbook was clear: break everything into small, independently deployable services, orchestrate them with Kubernetes, add a service mesh for observability, and watch your architecture diagrams grow into beautiful constellation maps. Conference talks celebrated the pattern. Job postings required experience with it. Entire platform teams existed to support it.

Then reality caught up. According to the CNCF Q1 2026 report, 42% of organizations that adopted microservices have now consolidated services back into larger deployable units. Service mesh adoption dropped from 18% to 8% in just two years. Gartner reports that 60% of teams regret the microservices decision for small-to-medium applications. The modular monolith isn’t staging a comeback—it’s winning the argument that microservices never should have had.

Neal Ford and Sam Newman, two of the most influential voices in software architecture, have declared 2026 the renaissance of the monolith. After years of championing distributed systems, even the architects who helped popularize microservices are acknowledging that the pattern has been dramatically overapplied.

The Distributed Systems Tax

Microservices promised agility: small teams, independent deploys, technology freedom. What they actually delivered was a distributed systems tax that compounds with every service you add—and most teams drastically underestimated the bill.

Each microservice needs its own CI/CD pipeline, deployment configuration, observability stack, security review, and on-call rotation. Research shows microservices require 25% more resources than monolithic architectures from operational complexity alone. For a 50-service deployment, distributed tracing infrastructure costs between $50,000 and $500,000 annually. Kubernetes demands one to two platform engineers for every 50 application developers—headcount that has nothing to do with shipping features.

The hidden costs go deeper. Distributed transactions require saga patterns or two-phase commits. Debugging a failed request means correlating trace IDs across multiple services, each with their own logging format and retention policies. Data consistency becomes a design problem you solve every single day instead of something your database handles automatically.

McKinsey has observed that the complexity introduced by modern distributed architectures often outpaces the organization’s ability to manage it, producing higher operational costs without commensurate productivity gains. More than 40% of organizations report regretting at least some of their microservices decisions, citing operational complexity and cost as the primary reasons.

What Amazon and Shopify Already Figured Out

The most persuasive evidence against microservices-as-default comes from companies that operate at scales most teams will never reach—and still chose to consolidate.

Amazon Prime Video’s video quality analysis team migrated from distributed microservices to a single-process monolith and achieved a 90% infrastructure cost reduction while improving their scaling capabilities. The team found that the overhead of orchestrating distributed components—network calls, data serialization, container management—consumed far more resources than the actual video analysis workload. If Amazon can’t make microservices work cost-effectively for an internal tool, the odds aren’t great for a Series B startup running twelve services with a team of eight.

Shopify tells an even more dramatic story. Their Ruby on Rails monolith contains roughly two million classes, over 4,000 components, and hundreds of concurrent contributors. During Black Friday 2025, it processed a peak of 30 terabytes per minute without incident. That’s not a toy application limping along on a monolith. That’s one of the highest-traffic commerce platforms on the internet, deliberately choosing a single deployable unit.

The secret isn’t that monoliths are inherently better. It’s that Shopify invested in making the monolith modular rather than splitting it apart. They use Packwerk, an open-source tool that enforces module boundaries at the code level. Each “pack” has explicit dependencies, clear public interfaces, and automated boundary checks. The result: team autonomy, clear ownership, and enforced contracts—without the distributed systems overhead.

The Modular Monolith: Not Your Legacy Codebase

The modular monolith isn’t your legacy spaghetti codebase with a new name. It’s a deliberately structured application where internal boundaries are as strict as service boundaries, but communication happens through in-process function calls instead of network requests. Think of it as microservices architecture principles applied within a single deployment unit.

The tooling has matured significantly in 2026. Spring Modulith 1.4, released in Q1, provides built-in verification that module boundaries adhere to architectural constraints. It checks for cyclic dependencies, validates that modules access other modules only through public API packages, and integrates with ArchUnit fitness functions for continuous architectural enforcement. JetBrains released dedicated Kotlin and IntelliJ IDEA guides for building and migrating to modular monoliths earlier this year, signaling that the pattern has moved firmly into the mainstream.

Here’s what you gain by keeping everything in one deployable unit.

Transactional consistency. No distributed transactions, no sagas, no eventual consistency headaches. A database transaction either commits or rolls back. Period.

Simplified debugging. A stack trace shows you the entire call path. No correlating trace IDs across fourteen services to find where a request failed.

Faster development velocity. Refactoring across module boundaries is a code change, not a coordinated multi-team API migration. When you’re building custom software for clients who need to iterate fast, this difference is measured in weeks, not days.

Lower infrastructure costs. One deployment target. One monitoring dashboard. One scaling knob. Teams report 40–90% reductions in infrastructure spend after consolidation.

When Microservices Still Make Sense

This isn’t a blanket condemnation of microservices. They solve real problems—when those problems actually exist.

Microservices earn their complexity when you have genuinely independent scaling requirements where one service handles 100x the traffic of another, when teams of 50 or more engineers need hard deployment boundaries to avoid stepping on each other, when regulatory isolation demands that certain data processing runs in a separate environment, or when polyglot requirements mean different services genuinely need different technology stacks.

Netflix, with its 700-plus microservices and dedicated platform team, genuinely needs that architecture. Uber, processing millions of rides across different business domains, benefits from independent deployment cycles. But for every Netflix, there are a thousand startups whose entire application could run comfortably on a single well-provisioned server.

The key word is “genuinely.” Most teams adopt microservices because they anticipate problems they don’t have yet. The CNCF data suggests that in practice, the anticipation tax is higher than the actual problems would have been. The approach we recommend is starting with a well-structured monolith and extracting services only when specific, measurable pain points demand it—not when a conference speaker makes it sound exciting.

A Practical Playbook for Modular Monoliths

Define module boundaries using domain-driven design

Each module should map to a bounded context. An “orders” module owns everything about order processing. A “payments” module owns payment logic. They communicate through well-defined interfaces, not shared database tables or global state. Getting these boundaries right upfront saves months of refactoring later.

Enforce boundaries with tooling, not discipline

Discipline doesn’t scale across teams or across time. Use Packwerk for Ruby, Spring Modulith for Java and Kotlin, or ArchUnit fitness functions for any JVM language. These tools make boundary violations a build failure, not a code review comment that gets ignored three sprints later.

Use asynchronous events for cross-module communication

Modules should publish domain events that other modules can subscribe to. This gives you the same loose coupling that microservices provide through message queues—but without the network hop, serialization overhead, or message broker infrastructure. When a module needs to react to something another module did, it listens for the event rather than calling the other module directly.

Plan your extraction strategy from day one

Design module boundaries so that if you ever need to extract a service, the seams are already there. A well-built modular monolith makes extraction a deployment decision, not an architectural rewrite. This is the kind of forward-thinking architecture that experienced engineering teams build from the start.

Invest in observability early

Running a monolith doesn’t mean you skip observability. Instrument module boundaries with metrics and traces from the beginning. When a module starts causing problems—whether it’s performance, reliability, or scaling—you’ll have the data to decide whether extraction is warranted rather than guessing based on gut feeling.

The Right Architecture for Your Actual Scale

The microservices-versus-monolith debate was always the wrong question. The right question is: does your architecture match the complexity your team can actually manage?

Forty-two percent of organizations learned this lesson the hard way. They split their systems into dozens of services, hired platform teams to manage the infrastructure, built complex CI/CD pipelines for each service, and then spent years consolidating back when the overhead eclipsed the benefits.

The modular monolith offers a better path for most teams. Start simple. Enforce boundaries with real tooling. Extract only when you have evidence—not intuition—that a service needs independence. The engineering teams shipping the fastest in 2026 aren’t the ones with the most services. They’re the ones with the right architecture for their actual scale.

If you’re building a new product or reconsidering your architecture, get in touch. We help teams design systems that match their real requirements—not the ones they imagine they’ll have in three years.

Our partnership models are designed for exactly this kind of architectural work—starting with what makes sense today and evolving as your product and team grow.