Few architecture decisions get made for worse reasons than the move to microservices. Teams adopt them because a conference talk was persuasive, because a new hire built them at their last company, or because "monolith" has quietly become an insult. Then eighteen months later they're operating forty services with three engineers, debugging a request that dies somewhere between service six and service nine, and wondering where their shipping velocity went.
The architecture isn't the villain. Microservices solve real problems, and at a certain scale they're the only sane option. The trouble is that they solve *specific* problems, and most teams reaching for them don't have those problems yet. Here's how to tell whether you do.
What microservices actually buy you
Strip away the hype and the benefits are concrete, and mostly organizational:
Notice the pattern: almost every benefit is about *decoupling teams and workloads*. If you have one team and one workload profile, the list above quietly evaporates.
What they cost, immediately
The costs, unlike the benefits, don't wait for scale. They arrive with the first service you split:
This is the distributed-systems tax, and it's charged whether or not you're getting the benefits. The whole decision comes down to whether the tax buys you out of problems you actually have.
The monolith isn't the thing you outgrow, it's the thing you earn the split with
The dirty secret of most microservice success stories, the Amazons and Netflixes of the conference circuit, is that they started as monoliths. The monolith found the product, found the domain boundaries the hard way, and got split once those boundaries were obvious and the teams existed to own the pieces. The architecture followed the understanding, not the other way around.
Splitting *before* you understand your domain is how you get the worst outcome in the space: the distributed monolith. Services that can't deploy independently because every change touches three of them, chatty synchronous call chains, shared databases behind the scenes. All of the tax, none of the benefits.
The strongest intermediate position deserves more respect than it gets: the modular monolith. One deployable, but internally organized into modules with real boundaries, each module owning its domain, exposing a narrow interface, and forbidden from reaching into another module's tables. You keep one build, one deploy, in-process calls and one database transaction, while making any future extraction cheap because the seams already exist. For most teams under about thirty engineers, this is the honest sweet spot.
| Monolith | Modular monolith | Microservices | |
|---|---|---|---|
| Deploys | One unit | One unit | Per service |
| Team coordination | High at scale | Module ownership | Low, by design |
| Data consistency | One transaction | One transaction | Sagas and eventual consistency |
| Operational overhead | One app to run | One app to run | Platform engineering |
| Debugging | Stack trace | Stack trace | Distributed tracing |
| Best for | Small teams, young products | Growing teams, clear domains | Many teams, proven boundaries |
The signals that it's actually time
Split when you can point at concrete, recurring pain, not at a diagram:
One of these is a conversation. Three of them is a plan.
How to split without regretting it
When the signals are real, how you split matters more than that you split:
The bottom line
Microservices are a tool for scaling organizations, not a maturity badge. The monolith-first path isn't a compromise, it's how the teams you admire actually got there: build the monolith with clean internal boundaries, watch for the concrete signals of deploy contention and divergent scaling, and split along seams the product has already proven, one service at a time. If you can't name the specific pain a split removes, you don't have a microservices problem yet, and the boring architecture is quietly the fastest one you can ship on.