For years, microservices have been touted as the future of software architecture — promising flexibility, independent deployments, and horizontal scaling. But now, some of the very companies that pioneered microservices are publicly moving back toward monolithic or modular architectures.
So what’s behind this shift?
Microservices: The Hype and the Reality
Benefits:
- Independent deployment and scaling
- Smaller, focused codebases
- Team autonomy for large organizations
Challenges:
- Operational overhead (networking, orchestration, deployment pipelines)
- Complex debugging and tracing
- Data consistency across services
- Difficult local development
- Steep learning curve for small teams
As your service count increases, so do the complexity and cost of coordination.
The Monolith Revival
A monolith is not “legacy” by default. In fact, many modern engineering teams are building modular monoliths — single-deployment systems with clean boundaries between internal modules.
Why teams are returning to monoliths:
- Faster development and debugging
- Simplified deployments and CI/CD
- Lower infrastructure cost and complexity
- Easier local development and onboarding
Real-World Examples
- Amazon started with a monolith (“Obidos”) and then moved to microservices for scale — but only after reaching massive scale.
- Segment (now part of Twilio) famously wrote about moving back to a monolith to regain developer velocity.
- Shopify has embraced a modular monolith approach to combine the best of both worlds.
So, Which Should You Choose?
| Criteria | Microservices | Monolith (Modular) |
|---|---|---|
| Team Size | Large, independent teams | Small to medium-sized teams |
| Deployment Frequency | High, per-service | Unified, simpler releases |
| Operational Maturity | Required (monitoring, tracing, etc.) | Minimal infra overhead |
| Scaling Requirements | Complex apps, per-service scaling | Simpler or early-stage products |
| Domain Complexity | Complex, bounded contexts | More centralized business logic |
