The Architectural Hype Trap
If there's one decision I've seen destroy more projects than any other, it's choosing microservices when a monolith would have been perfect. And it's not the teams' fault — the industry has been selling microservices as the universal solution for years.
They're not. They're one more tool, and like any tool, they have a context where they shine and another where they destroy.
When the Monolith Wins
A well-designed monolith is the right choice when:
- The team is small (fewer than 10 developers). Service coordination has an enormous operational cost.
- The domain isn't clear. If you can't define clear boundaries between services, you'll end up with a distributed monolith — the worst of both worlds.
- You're in early product phase. You need to iterate fast, change data models, pivot. A monolith gives you that agility.
- You don't have mature DevOps infrastructure. Microservices require robust CI/CD, container orchestration, service mesh, distributed monitoring...
When Microservices Justify Their Cost
Microservices are the right choice when:
- Large independent teams need to deploy without coordination. Netflix, Amazon, Google — they have thousands of engineers.
- Differential scale: one part of the system receives 100x more traffic than the rest.
- Heterogeneous technology: different system parts benefit from different stacks (Python for ML, Go for high-performance APIs, Node.js for real-time).
- Extreme availability requirements: if the payments module fails, the catalog should keep working.
The Pattern That Really Works: The Modular Monolith
In my experience, the most successful pattern for most startups and medium companies is the modular monolith. It's a monolith, but with well-defined internal boundaries:
- Modules with clear public interfaces
- Inter-module communication via interfaces, not direct access to foreign tables
- Each module can be extracted to an independent service when (and only when) justified
Django does this naturally with its apps system. Next.js with its module structure. The key is to design for separation, but deploy as a unit.
The Hidden Cost
What nobody tells you about microservices: distributed debugging is an order of magnitude harder. A request traversing 5 services can fail in any of them, and tracing the error requires tooling that has its own complexity.
My advice after 20 years: start with a modular monolith. Measure. Identify real bottlenecks. Extract only what needs to scale independently. And never, ever choose microservices because it's trendy.