When NOT to Use Microservices

1. What the Industry Learned

Knowing when not to split a system is harder than knowing how to split one, and it is worth more. Anyone who learned microservices from enthusiastic blog posts has a list of benefits. Anyone who has run them for a few years has a list of costs. This lesson is the second list.

The industry learned this by paying for it. Over the last few years a visible number of teams have merged services back into larger pieces. Merging services back together like this is called consolidation, and two of those teams wrote up what they found.

• Amazon's Prime Video video-quality team published the most cited account. They merged a distributed analysis pipeline, built from serverless functions and microservices, into a single process. A serverless function is a small piece of code that a cloud provider runs on demand. They reported a 90% infrastructure cost reduction alongside better scaling.
  • Here is the detail that makes the story useful. The distributed design's costs came from moving data between components. The system paid for orchestration, which is the work of coordinating all the pieces, and it paid to ship video frames through intermediate storage again and again. That is exactly the cost that disappears when components share one process.
• Segment, years earlier, published an honest account of the same experience. They split into one microservice per destination, then deliberately merged back into a monolith. The operational load had overwhelmed the team: dozens of repositories, queues, and on-call rotations for one logical function.

These are not two isolated stories. Surveys of teams that adopted microservices keep finding a large minority moving services back together, and the two reasons they give are always the same: operational complexity and cost.

None of this means microservices are a bad idea. It means the costs are now well documented, and adopting the architecture without counting them is the mistake this lesson exists to prevent.

2. The Six Situations Where Splitting Is the Wrong Choice

1. The team is small. One team of eight engineers gains nothing from twelve services. The benefit that justifies the architecture is deployment autonomy, meaning each team ships without waiting on any other team, and that benefit needs multiple teams to exist first. Every service adds a pipeline, dashboards, alerts, and one more thing an engineer can be paged for at night. Eight people have to handle all of it. Here is the rule to remember. Until coordination between teams is a measurable bottleneck, the coordination problem microservices solve does not exist yet.

2. The domain is still changing. Service boundaries are predictions about which parts of the system change independently. Before product-market fit, the point where users want the product and the feature set stops churning, those predictions are guesses. Wrong guesses are expensive in exactly the place where microservices make change hard: across service boundaries. Inside a monolith, a boundary mistake is a refactor. Across services, it becomes a data migration, an API versioning problem, and a multi-team project. API versioning means keeping old and new versions of an interface running at the same time.

3. The operations platform is missing. Microservices assume a working platform underneath: CI/CD, centralized logging, distributed tracing, infrastructure as code, and real on-call. CI/CD means automated build and deploy pipelines. Distributed tracing means following one request as it crosses services. Infrastructure as code means servers and configuration defined in files rather than set up by hand. Without those, every incident becomes a slow manual search across machines you cannot inspect, and adopting the architecture early is how you get outages that last for days.

4. The load is uniform and modest. Independent scaling is worth it when one component needs 10 times the capacity of the rest. When the whole system scales together, copies of a monolith behind a load balancer do the same job with far fewer parts to operate. A load balancer is a router that spreads incoming requests across those copies.

5. The workflow is one tight sequence. If every user action flows through the same five steps in order, splitting the steps into services gives you no independence. The services still ship and fail together, so you add five network hops and gain nothing. This is how distributed monoliths get built, one reasonable-sounding split at a time. A distributed monolith is a system with the operational cost of microservices and the coupling of a monolith, which is the worst of both.

6. Low latency is the product. Each service boundary adds a network round trip plus serialization, which is the work of converting data to bytes for the network and back. Systems with hard per-request latency budgets, such as trading, real-time bidding, and gameplay, keep their hot path inside as few processes as possible. The hot path is the code that every request runs through.

Put together, these six situations become one decision flow.

3. The Positive Checklist

The opposite list is short, and stating it makes any "when not" answer stronger. Microservices are worth their cost when most of these are true:

1. Multiple teams block each other's releases today, not hypothetically.
2. Specific components have wildly different scaling, reliability, or compliance needs. Compliance means legal or regulatory rules, such as where certain data must live.
3. The domain is stable enough that boundaries drawn now will still be right later.
4. The organization already operates software well: automated deploys, observability, and on-call. Observability is the logs, metrics, and traces that show what the system is doing.
5. There is a plan for the hard parts: data ownership, cross-service consistency, failure handling.

💡 The strongest thing you can do in this conversation is to name the evidence you would collect before deciding. Say: "I would look at how often team A's release blocks team B, and whether any component's load profile diverges from the rest. If neither appears in the data, I keep the modular monolith." (A modular monolith is one deployable app with clean module boundaries inside it.) Deciding from evidence rather than from what is popular is the whole skill.

4. How to Explain It

This decision comes to you in a few forms. Someone proposes breaking up the monolith. A team sketches twelve services for a product with three customers. Or you are handed a small problem and have to decide how many services it deserves, which is the moment people start drawing boxes without thinking.

The 30-second answer: "I would not use microservices with a small team, an unstable domain, or a missing operations platform. I also would not use them for performance. They add latency per request, and the industry has spent the last few years consolidating services back for exactly this reason. Prime Video's team cut infrastructure costs 90% by merging a pipeline into one process. My default is a modular monolith. I split when there is evidence: teams blocking each other's releases, or a component whose scaling or reliability needs genuinely diverge from the rest."

Questions that usually follow:

1. "So when is it worth it despite the costs?" Run the positive checklist. Multiple teams with measurable release contention, meaning releases that block each other. Scaling or compliance needs that genuinely differ. Stable boundaries. Real operational maturity. Then name a company-shaped example: hundreds of engineers, tens of independently deployable products.
2. "Your company already has 40 microservices and 15 engineers. What do you do?" Do not immediately propose a rewrite in either direction. Reduce the immediate damage first. Consolidate the services that always change together, because they are really one service paying for several pipelines. Invest in the observability that makes the rest manageable. Then stop new splits until each one has a team that will own it.

A common mistake: treating "when not" as a trick question, and answering that microservices are always the right long-term goal and you just need to get there gradually. That is a decade-old assumption, and none of the recent evidence supports it.

5. TL;DR