Here's a scene most senior engineers have lived through. A team of maybe 20 people spends a quarter moving a working monolith to a microservices architecture, splitting it into a dozen services. The pitch was compelling: independent deploys, better scalability, "the way real tech companies build software." Nine months later, the same team is debugging a checkout failure that touches four services, three different logging formats, and a distributed trace that keeps dropping spans right where the actual bug lives. The release that used to take twenty minutes now takes an afternoon of coordinating version compatibility across teams.
Nobody planned for this outcome. But it's the default outcome, because most teams that adopt a microservices architecture don't actually have the problem microservices were built to solve.
That's the argument here, stated plainly: most migrations happen because it's what big companies do, because it looks good on a resume, or because someone read a conference talk from a company operating at a completely different scale. The real result is almost always more operational complexity, more coordination overhead, and none of the benefit that made the pattern worth inventing in the first place.
The problem a microservices architecture is actually built to solve
Splitting a system into services isn't about code cleanliness. It solves one specific problem: large numbers of engineers who need to work independently on different parts of a system, deploy on their own schedules, and scale pieces separately without stepping on each other.
If your team is eight or ten engineers, that problem doesn't exist yet. A team that size can review each other's code, understand the whole system, and ship a monolith together without a change advisory board. A microservices architecture gives that team nothing. What it does give them is a distributed failure surface, network calls where a function call used to be, and a data consistency problem that a single database transaction used to handle for free.
The question almost nobody asks before migrating is uncomfortably simple: what is actually slow or broken today? If the honest answer is "deploys take too long" or "the codebase is a mess," that's an engineering discipline problem, not an architecture problem. It gets fixed with better CI pipelines and clear module boundaries inside the existing codebase. It does not get fixed by cutting the system into pieces that now talk to each other over the network.
Why microservices became the default answer anyway
There's a cultural reason this keeps happening, and it's worth saying out loud. Microservices sound like serious engineering. It's what Netflix does, what Amazon does, what Uber does. Putting it on a technical roadmap signals ambition, even when the product in question handles a fraction of a percent of the traffic those companies deal with.
The part that gets lost is that none of those companies adopted a distributed architecture because a blog post told them to. They did it because they had thousands of engineers touching the same codebase and shipping a single monolith had become physically impossible without breaking something else every week. Netflix didn't split its systems to look good in a keynote. It did it because coordinating hundreds of teams around one deploy pipeline had stopped working.
Copying the solution without having the underlying problem is the actual mistake. It's buying the exact car a race driver uses and expecting that alone to make you faster. The tool doesn't manufacture the problem that justified it.
When the organizational pain actually justifies a microservices architecture
None of this means microservices are always the wrong call. There are real, specific situations where splitting a system is the right decision, and it's worth naming them precisely, because the honest answer isn't "never microservices." It's "microservices when this particular problem shows up."
The first and most common case among companies that have already scaled: large teams stepping on each other inside one monolith. Once you have 60, 100, or 150 engineers working in the same repository, merges turn painful, one team's deploy blocks everyone else's, and a bug in a billing module can take down checkout because everything runs in the same process. That's a real coordination problem, and splitting the system into independent services solves it by giving each team its own deploy cadence, its own blast radius, and its own release schedule.
The second case is a genuine need to scale parts of the system independently. Say an image processing pipeline burns ten times the CPU of the rest of the application. In a monolith, that forces you to scale the entire app horizontally just to give that one piece more resources. Pulling it into its own service lets it scale against its own demand curve without dragging the rest of the system along. This is different from splitting everything "just in case." It's a decision driven by a resource metric that's already causing pain today.
Notice the pattern across all three: the pain exists before the architecture change. Nobody migrates to prevent a hypothetical future scaling problem. They migrate because the problem is already happening and it's already costing money, time, or people.
The cost nobody puts on the architecture diagram
When that problem doesn't exist yet, adopting a microservices architecture isn't a neutral choice. It has a real cost, paid on several fronts at once.
The first is deployment. Going from "one app, one deploy" to "twenty services with compatible versions that all need to be coordinated" multiplies the number of things that can go wrong. Now you need contract versioning between services, feature flags for gradual rollouts, and a separate CI/CD pipeline per service instead of one.
The second is observability. In a monolith, a stack trace tells you exactly where something broke. In a distributed system, that same error might have crossed five services before it surfaced, and without properly implemented distributed tracing (which isn't free to build or maintain) you'll spend hours manually reconstructing the path a single request took.
The third is data consistency. In a monolith, a database transaction gives you atomicity almost for free. In a microservices architecture, that same operation now touches multiple independent databases, and suddenly you're implementing patterns like sagas or eventual consistency to solve a problem a single `BEGIN` and `COMMIT` used to handle.
The fourth is network latency. Every function call that used to cost nanoseconds is now an HTTP or gRPC call crossing the network, with its own latency budget, its own timeouts, and its own failure modes. A flow that used to be three functions calling each other in sequence is now three services calling each other, and any one of those calls can fail in ways a monolith never had to account for.
None of these costs are inherently bad. They're the price of solving a real coordination or scaling problem. The issue is paying them without needing to, because then they're pure cost with nothing on the other side of the ledger.
A quick test for where your team actually stands
There's a simple, slightly uncomfortable test that cuts through this. Ask: if the team froze exactly as it is today, would the monolith still be a problem? If the answer is no, because the pain is really about a team that might grow, a part of the system that might need to scale "eventually," or a distributed architecture that just looks more impressive, then there's no architecture problem here. There's an untested assumption.
If the answer is yes, because teams are already blocking each other today, because one part of the system is already consuming disproportionate resources today, or because two business domains are already getting in each other's way today, then the case is real. And in that case, a microservices architecture isn't a trend. It's the right tool for a problem that's already costing something.
Name the problem before you draw the service diagram
A microservices architecture isn't good or bad on its own. It's a tool with a high operational cost that only pays off when it solves a coordination or scaling problem that already exists, not one you're anticipating. Migrating without that problem doesn't make a team more technically mature. It gives a team the exact same business complexity it had before, now spread across twenty repositories, with a larger failure surface and fewer people who can hold the whole system in their head. If a team walks into a room to make this call and nobody can name, with actual numbers, what's slow or broken today, the right answer isn't "which microservices architecture should we build." It's staying in the monolith one more cycle and fixing the problem that's actually there.
