Splitting everything into microservices became the default for "serious" teams, and left many with distributed systems far more complex than the problems they solve. This guide lays out the trade-offs, the evidence, and a way to size architecture to your org instead of to fashion.
The default that quietly costs you: split into services because that's what serious teams do, and buy the full operational overhead of distribution (deploy, monitor, on-call, distributed debugging) to solve a coordination problem you don't have at your team size.
The disciplined alternative: get modularity almost always, take on distribution only when your org size and real scaling needs justify it, and let Conway's Law, not fashion, decide the architecture.
Almost Always Yes
Clear boundaries, defined interfaces, components that evolve independently. This is nearly always good, and you want it in every architecture.
Only Sometimes
Deploying those components as separate networked services. It's a real cost (operational overhead, network failure, distributed data) that you should only pay when the benefit is real.
the Deciding Variable
Conway's Law says the architecture that works matches how your teams are organized to communicate. A few teams point to a modular monolith. Many independent teams at scale point to splitting.
A few teams, default to a modular monolith. Many teams that must deploy and scale independently, microservices start to earn their cost. Size to the org, not the ambition.
If teams need to avoid stepping on each other, module boundaries in a monolith deliver that. Only genuine independent-deploy-at-scale needs justify splitting.
That's a legitimate reason to extract one service. "It would be cleaner" is not.
Every service adds deploy, monitor, on-call, and debugging load. If you can't staff it, splitting costs more than it returns. That's the Prime Video lesson.
No. One Amazon team right-sized one internal tool from a distributed serverless design back to a monolith, cutting cost about 90% because the distributed version scaled to only 5% of target load. It's evidence microservices can be the wrong fit for a problem, not that they never work.
A single deployable application organized into well-bounded components with clear interfaces. Modularity without distribution. Shopify runs its core this way at scale to keep boundaries clean and operational cost low.
When you have many independent teams that genuinely need to deploy and scale independently, and can staff the operational overhead. That's roughly the scale where the coordination benefit outweighs the distribution cost.
Start from your org. How many independent teams do you have, and how do they need to coordinate? Conway's Law says the architecture should match that.
VPs of Engineering, heads of architecture, and engineering directors deciding how to structure systems as their teams grow.
Drop your details and we'll send Micro-Frontends and Modular Monoliths straight to your inbox - no spam, unsubscribe anytime.
Talk through how this applies to your roadmap with our engineering leads - a working session, not a sales pitch.
Download White Paper