Great Stack to Doesn't Work — Bonus
Monolith vs Microservices: The 2026 Verdict
The debate that won't die, finally given an honest answer.
Every year someone writes "microservices are dead" and someone else writes "monoliths don't scale." Both are wrong. Both are right. The answer has never been the architecture — it's the team.
The Pendulum in 2026
The industry swung hard toward microservices between 2015-2020. Netflix, Uber, and Spotify published their architectures. Everyone wanted to be Netflix. Nobody had Netflix's engineering team.
The result: thousands of companies with 50 microservices, 3 developers, and a Kubernetes cluster that nobody fully understands. Deploy times went up. Debugging went from "read the stack trace" to "correlate logs across 12 services." Latency increased because every feature required 7 network calls.
By 2023, the correction started. Amazon's Prime Video team moved from microservices back to a monolith and reduced costs by 90%. Shopify stayed monolith and scaled to billions. Basecamp never left the monolith.
In 2026, the consensus is forming around something less dramatic: start monolith, extract when you must, and extract only the pieces that need independent scaling or deployment.
When the Monolith Wins
The monolith wins when your team is small (under 30 engineers), your domain boundaries are still evolving, and deployment simplicity matters more than independent scaling.
A well-structured monolith with clear module boundaries gives you all the organizational benefits of microservices — separation of concerns, team ownership, independent development — without the operational complexity of distributed systems.
Refactoring is a function call, not a contract negotiation. Testing is run the test suite, not spin up 8 services with Docker Compose and pray they connect. Debugging is a stack trace, not a distributed trace across 5 services.
When Microservices Win
Microservices win when you have genuine organizational scaling needs: 100+ engineers who can't work on the same codebase without stepping on each other. Or when you have genuine technical scaling needs: one component needs 50 instances while another needs 2, and scaling them together wastes resources.
Other valid reasons:
- Technology diversity. Your ML team needs Python, your API team uses Go, your data pipeline is in Scala. A monolith forces one language.
- Independent deployment cadence. The payments team deploys hourly. The billing team deploys weekly. Coupling their deployments creates friction.
- Fault isolation. A memory leak in the recommendation engine shouldn't take down the checkout flow.
The Modular Monolith: The Middle Ground Nobody Talks About
A modular monolith enforces module boundaries within a single deployable unit. Each module has its own domain, its own database schema (logical separation), and communicates with other modules through defined interfaces — not direct database queries.
src/
modules/
orders/
api/ # Public interface
internal/ # Private implementation
schema/ # Database migrations
payments/
api/
internal/
schema/
users/
api/
internal/
schema/
Modules can't import each other's internals. They interact through API layers. The compiler (or linter) enforces the boundaries.
When a module outgrows the monolith — it needs independent scaling, a different language, or a separate deployment cadence — you extract it. The interfaces already exist. The extraction is surgical, not exploratory.
This is the Strangler Fig pattern done proactively: build the boundaries first, extract later, only when the pain justifies the complexity.
The Decision Framework
Choose monolith when:
- Team < 30 engineers
- Domain boundaries are still being discovered
- Time-to-market matters more than scalability
- You don't have dedicated DevOps/SRE capacity
Choose modular monolith when:
- Team 15-80 engineers
- Domain boundaries are clear but scaling needs are uniform
- You want the option to extract services later without rewriting
Choose microservices when:
- Team > 50 engineers with clear team ownership boundaries
- Components have genuinely different scaling requirements
- You have the infrastructure team to support distributed systems
- Independent deployment cadence is a hard requirement
Never choose microservices because:
- "We might need to scale" — solve that problem when you have it
- "Netflix does it" — you're not Netflix
- "It's the modern way" — modernity is not a feature
The Uncomfortable Truth
The biggest predictor of microservices success isn't the architecture. It's the investment in platform engineering. Without centralized observability, automated service provisioning, standardized CI/CD, and shared libraries for cross-cutting concerns, every team reinvents the wheel and your "independent services" become independently broken in unique ways.
If you can't afford a platform team, you can't afford microservices.
Over to You
Monolith or microservices in 2026 — where do you stand? Has anyone successfully gone back from microservices to a monolith?
If you enjoyed this, I write about production engineering, AI systems, and the messy reality of building software at scale.
Follow me:
This is part of the **Great Stack to Doesn't Work* series — a survival guide for when everything goes wrong in production. Follow the series to catch every episode.*
Top comments (0)