Reboot Germany

Microservices vs. Monolith 2026: When Refactoring Really Pays Off

Q: What is a distributed monolith?

An architecture that looks like microservices (many services, network communication) but behaves like a monolith: all services must be deployed together, share data, and cannot scale independently. It’s the worst-case outcome of a poorly planned microservices migration - more complexity, zero of the promised autonomy.

By Benedikt Langer March 31, 2026 6 min read

Microservices vs. Monolith 2026: When Refactoring Really Pays Off

42 percent of companies that adopted microservices are now consolidating services back into larger units. Amazon Prime Video cut infrastructure costs by 90 percent by migrating its video quality analysis service from distributed microservices back to a single-process monolith. Service mesh adoption dropped from 18 to 8 percent in two years. Microservices haven’t failed – but the blanket recommendation to break everything into microservices has. 2026 is the year of nuanced architectural decisions: monolith, modular monolith, or microservices – depending on team size, scaling requirements, and operational maturity.

TL;DR

42 percent consolidate back: According to the CNCF 2025 Survey, 42 percent of microservices adopters have recombined services. Primary drivers: debugging complexity, operational overhead, and network latency.
Amazon Prime Video: 90 percent infrastructure cost savings by migrating its video quality analysis service – from a distributed microservices architecture to a single-process monolith.
3.75x to 6x higher infrastructure costs for microservices versus monoliths delivering equivalent functionality. Enterprise monolith: ~€15,000/month vs. microservices: €40,000-€65,000/month.
The modular monolith as the middle path: Modules communicate via well-defined interfaces, use separate database schemas within a shared database, and can be extracted into independent services if needed. Architectural rigor without operational overhead.
Decision rule: Fewer than 100 developers = modular monolith. More than 100 developers with genuinely independent scaling needs = microservices. Fewer than 10 = classic monolith.

The Microservices Reality Check: What the Data Shows

The microservices wave of the 2010s promised simplicity: split your application into small, independent services – and gain speed, scalability, and team autonomy. Netflix, Amazon, and Google led the way. Thousands of companies followed.

Ten years later, reality has set in: the promise holds – but only under specific conditions. The CNCF 2025 Survey documents the counter-trend: 42 percent of organizations that adopted microservices are now consolidating services – not back to the monoliths of the early 2000s, but into larger, better-bounded deployment units.

Symptoms driving consolidation: Debugging across service boundaries is exponentially harder than inside a single process. Every network call between services introduces a potential failure point. And the operational overhead of managing dozens – or hundreds – of services demands a dedicated Platform Engineering team, which many mid-sized firms simply lack.

CNCF Survey 2025

42 %

of microservices adopters are consolidating services back

Source: CNCF Cloud Native Survey, 2025

Amazon Prime Video: The Case Study That Changed Everything

In May 2023, the Amazon Prime Video engineering team published an architecture analysis that shook the cloud community. Its video quality analysis service had been built as a distributed microservices architecture using AWS Step Functions and Lambda. Costs were prohibitive; scaling was constrained.

The solution? Migrate to a single-process monolith. The result? A 90 percent reduction in infrastructure costs – and improved scalability. Why? Because the service had no real need for independent scaling of individual components. All parts processed the same video stream. The microservices architecture introduced network overhead and orchestration complexity – without delivering tangible value.

The lesson isn’t that microservices are bad. It’s that microservices solve one specific problem: independent scaling and deployment by autonomous teams. If that problem doesn’t exist, microservices generate only cost.

The Cost Truth: Monolith vs. Microservices

The numbers are unambiguous. Microservices infrastructures cost 3.75x to 6x more than equivalent monoliths. At enterprise scale, that means: ~€15,000/month for a monolith versus €40,000-€65,000/month for an equivalent microservices architecture – once infrastructure, operations, platform teams, and coordination overhead are factored in.

Personnel costs amplify the gap. A modular monolith requires 1-2 operations engineers. An equivalent microservices architecture demands 2-4 Platform Engineers plus additional operational effort distributed across product teams. With annual salaries for Platform Engineers ranging from €140,000 to €180,000 (DevOps Salary Reports 2025), personnel costs dwarf infrastructure expenses.

For DACH companies with 10-50 developers, the math is clear: a modular monolith delivers 90 percent of the architectural benefits at a fraction of the cost. Microservices only pay off when Conway’s Law forces the architecture – when organizational structure is so large and fragmented that teams must deploy independently.

// Quote

90 percent of microservices architectures are still deployed like monoliths. Organizations have split the services – but not the deployment pipeline.

The New Stack · Why 90% of Microservices Still Ship Like Monoliths, 2025

The Modular Monolith: The Pragmatic Answer

The modular monolith isn’t a compromise. It’s a distinct architectural choice. In a well-designed modular monolith, modules communicate via defined interfaces, use separate database schemas within a shared database, and can be extracted into standalone services on demand.

The key is “on demand.” Rather than proactively splitting everything into services – and paying the overhead immediately – the modular monolith enforces module boundaries without network overhead or deployment complexity. If a module truly needs independent scaling, it can be extracted. If not, it stays in the monolith.

A systematic literature review presented at the ACM Conference on Software Architecture Trends (2024) confirms: the modular monolith is no longer a niche pattern – it’s a recognized architecture sitting squarely between the classic monolith and distributed microservices. Its blend of operational simplicity, modularity, and maintainability hits the sweet spot for companies with 10-100 developers.

The Decision Matrix: Which Architecture When?

Classic Monolith: Fewer than 10 developers. MVP, prototype, or first product version. Speed over architecture. The fastest path to product-market fit. Refactoring comes later – once you know what works.

Modular Monolith: 10-100 developers. Thousands to millions of users (not billions). Fewer than 5 Platform Engineers. Priority: cost efficiency and development velocity. The architecture of choice for DACH mid-market firms.

Microservices: More than 100 developers facing Conway’s Law challenges. Genuine need for independent scaling (e.g., a payment service requiring 50x more compute than other services). Polyglot requirements (ML in Python, core logic in Java). Regulatory isolation mandates physical separation (PCI Compliance for payment processing).

The most common misstep: Companies with 20 developers adopting microservices because Netflix did it. Netflix has 10,000 developers. The organizational complexity microservices solve simply doesn’t exist at 20 developers. The result? A distributed monolith – combining all the downsides of both worlds, with none of the benefits.

Conclusion

The microservices-vs-monolith debate is no longer ideological in 2026. It’s a pragmatic decision grounded in team size, scaling requirements, and operational maturity. Forty-two percent are consolidating back. Amazon saves 90 percent with a monolith. Microservices cost 3.75x to 6x more than monoliths. For the DACH mid-market, the modular monolith is the right architecture in 90 percent of cases: architectural rigor without the operational overhead of distributed systems. The question isn’t monolith or microservices. The question is: What specific problem does this architecture solve? If the answer is “team autonomy at 200 developers,” microservices make sense. If the answer is “we want to look modern,” it’ll get expensive.

Frequently Asked Questions

Have microservices failed?

No. Microservices solve a real problem: independent scaling and deployment for large, autonomous teams. What failed was the blanket recommendation to decompose every application into microservices. Forty-two percent are consolidating because they realized the overhead outweighs the benefits – when the underlying problem doesn’t even exist.

What is a distributed monolith?

An architecture that looks like microservices (many services, network communication) but behaves like a monolith: all services must be deployed together, share data, and cannot scale independently. It’s the worst-case outcome of a poorly planned microservices migration – more complexity, zero of the promised autonomy.

How do I know my monolith is getting too big?

Three warning signs: First, deployment conflicts – teams blocking each other during releases. Second, build times exceeding 15 minutes. Third, a change in Module A breaking tests in Module B – even though the modules should be independent. These signal missing module boundaries – not necessarily a need to jump to microservices.

How do I migrate from microservices to a modular monolith?

Incrementally – not in a Big Bang. Identify services that are always deployed together and don’t require independent scaling. Merge them as modules into a shared codebase. Switch communication from HTTP/gRPC to in-process calls. Consolidate databases – but retain separate schemas. Consolidate three to five services per quarter.

Which language works best for a modular monolith?

Java (with Spring Modulith), .NET (with Domain-Driven Design patterns), and Go (with clear package structure) offer the strongest tooling support. Since 2024, Spring Modulith provides explicit module boundary checks and event-based inter-module communication. In .NET, Vertical Slice Architecture is the preferred approach. Node.js/TypeScript is viable – but module isolation requires stricter discipline.