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.
Clear boundaries, defined interfaces, components that evolve independently. This is nearly always good, and you want it in every architecture.
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.
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.
The industry oversold splitting. Microservices are powerful where independent teams genuinely need to deploy and scale independently, and expensive mistakes below it. Get the modularity, take on distribution only when justified, and keep boundaries clean so you can extract a service later, on evidence.
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.
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.
VPs of Engineering, heads of architecture, and engineering directors deciding how to structure systems as their teams grow.
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.
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.
