A Series B startup once showed me their architecture diagram with real pride: forty-three microservices, a service mesh, event buses, the works. Then I asked how long it took to ship a change to their checkout flow. The room went quiet. The answer was eleven days — because a one-line price change touched six services owned by four teams, and someone had to coordinate the deploys.
They didn't have a microservices architecture. They had a distributed monolith with extra network calls, and it was slower to change than the codebase they'd fled.
The pain you're solving for is organizational, not technical
Microservices are, at heart, a solution to a people problem. When you have too many engineers stepping on each other in one codebase — merge conflicts, coupled deploys, a release train nobody can slow down — splitting the system lets teams own and ship independently. That's the win. Everything else people cite (scaling, resilience, polyglot freedom) is usually secondary and often achievable inside a well-structured monolith.
So the honest first question isn't "how do we decompose our domain?" It's "does our current architecture actually hurt, and where?" If you have eight engineers and one deploy pipeline, microservices will add distributed-systems tax — network failures, eventual consistency, distributed tracing, saga patterns for what used to be a database transaction — and hand you almost none of the benefit.
If you can't cleanly draw a module boundary inside your monolith, splitting it across a network won't make the boundary appear. It'll just make the mess harder to see.
Signals it actually hurts
In my engagements, I look for concrete, measurable pain before endorsing any split. A few of the signals that matter:
- Deploy coupling. Independent features can't ship independently because they share a release. Teams queue behind each other.
- Divergent scaling needs. One component — video transcoding, report generation, a search index — needs 20x the resources of everything else, and you're paying to scale the whole app to feed it.
- Blast radius. A memory leak in a rarely used admin feature takes down checkout, because it's all one process.
- Team topology. You have five teams and one codebase, and coordination cost is now visible on the roadmap.
Notice what's not on that list: "we read that Netflix does it," or "it feels more modern." Those aren't signals. They're fashion.
Do the boring work first: the modular monolith
Before you touch the network, earn the boundaries inside your existing app. A modular monolith — clear modules with explicit interfaces, no reaching into another module's tables, dependencies pointing one direction — gives you 80% of the architectural clarity at 5% of the operational cost. You still deploy one artifact. You still get one database transaction. But the seams are now real.
This is the highest-leverage move most teams skip. If your team can hold those internal boundaries for six months without cheating, extraction later becomes almost mechanical. If they can't hold the boundary in-process, they certainly won't hold it across a network — they'll just add latency and retries to the same tangle.
When you do extract, do it one seam at a time
Pick the module with the clearest boundary and the strongest independent reason to move — usually the one with divergent scaling or a different team. Extract that one. Run it in production. Feel the operational weight: the on-call, the observability, the deployment pipeline, the contract versioning. Then decide whether the next one is worth it. Most companies discover that three or four well-chosen services capture nearly all the benefit, and the remaining thirty would just be pain.
The costs nobody puts on the slide
A microservice is not free the day you create it. It's a standing liability: its own CI/CD, its own dashboards and alerts, its own secrets and dependency upgrades, its own place in the on-call rotation. Multiply by forty and you've built a second full-time job that has nothing to do with your product.
The other quiet cost is debugging. In a monolith, a stack trace tells the whole story. Across services, a single user action fans out through a dozen hops, and you're stitching together correlation IDs across logs at 2 a.m. to answer a question a single breakpoint would have answered before. Budget for that reality, or don't sign up for it.
Where to start on Monday
Don't schedule a migration. Schedule an honest audit. Write down the actual pain — deploy times, incident blast radius, the features stuck in a coordination queue — with numbers next to each. If the list is thin, your answer is a modular monolith and better module discipline, not a distributed system.
If the pain is real and localized, extract exactly one service, the one the evidence points to, and live with it before extracting a second. Let the architecture follow the pain, not the conference talk.
Microservices are a tool for a specific kind of hurt. Before you reach for them, make sure you can name where it hurts — and that a simpler cut wouldn't fix it just as well.