When NOT to Use Microservices

1. The Question Behind the Question

"When would you not use microservices?" is now one of the most common senior-level architecture questions. It is worth understanding why interviewers reach for it: memorization cannot answer it well. A candidate who learned microservices from enthusiastic blog posts has a list of benefits; a candidate who has lived with them has a list of invoices. The question sorts the two groups in about a minute.

It also reflects where the industry actually is. The last few years produced a visible consolidation wave. Consolidation here means merging services back into larger pieces. Interviewers expect you to know about it:

• A survey by the Cloud Native Computing Foundation (CNCF), the group behind Kubernetes, found 42% of organizations that adopted microservices consolidating services back into larger deployable units. A deployable unit is the thing you build, test, and release as one piece.
• Amazon's Prime Video video-quality team published the era's most cited case study. They merged a distributed analysis pipeline, built from serverless functions (small pieces of code a cloud provider runs on demand) and microservices, into a single process. They reported a 90% infrastructure cost reduction alongside better scaling.
  • Here is the detail that makes the story useful in interviews. The distributed design's costs came from moving data between components. The system paid for orchestration, the work of coordinating all the pieces, and it paid to ship video frames through intermediate storage again and again. That is exactly the tax that disappears when components share one process.
• Thoughtworks and others report over 40% of organizations expressing regret about at least part of their microservices adoption. The reasons they cite are operational complexity and cost.
• Segment, years earlier, published a candid account of the same journey. They split into one microservice per destination, then deliberately merged back into a monolith. The operational load had overwhelmed the team: dozens of repos, queues, and on-call surfaces for one logical function.

None of this means microservices are over. It means the architecture has a price list now. Defaulting to it without reading the prices is the mark of a junior answer.

2. The Six Situations Where Splitting Is the Wrong Call

1. The team is small. One team of eight engineers gains nothing from twelve services. The benefit that justifies the architecture is deployment autonomy (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 an on-call surface (one more thing an engineer can be paged for at night), and eight people absorb all of it. Here is a heuristic worth quoting. Until coordination between teams is a measurable bottleneck, the coordination problem microservices solve does not exist yet.

2. The domain is still moving. Service boundaries are bets 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 bets 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, API versioning (keeping old and new API versions running), and a multi-team project.

3. The operational floor is missing. Microservices assume a working platform underneath: CI/CD, centralized logging, distributed tracing (following one request as it crosses services), infrastructure as code, and real on-call. CI/CD means automated build and deploy pipelines; infrastructure as code means servers and configs defined in files, not set up by hand. Without those, every incident turns into archaeology: digging through machines you cannot see into. Adopting the architecture before the platform is how you get outages measured in days.

4. The load is uniform and modest. Independent scaling pays off 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 (a router that spreads incoming requests across the copies) do the same job. They do it with a fraction of the moving parts.

5. The workflow is one tight sequence. If every user action flows through the same five steps in order, splitting the steps into services buys 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, the worst of both.

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

Put together, these six situations become a decision flow you can walk through out loud.

3. The Positive Checklist

The inverse list is short. Stating it makes any "when not" answer stronger. Microservices earn 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 survive.
4. The organization already operates software well: automated deploys, observability (logs, metrics, and traces that show what the system is doing), and on-call.
5. There is a plan for the hard parts: data ownership, cross-service consistency, failure handling.

💡 The strongest single move in this conversation is naming 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 shows up in the data, I keep the modular monolith." (A modular monolith is one deployable app with clean module boundaries inside it.) Deciding from evidence, not from fashion, is exactly what the question exists to detect.

4. In the Interview

The question arrives in a few direct forms. "When would you not use microservices?" "Your team wants to split up the monolith. What do you ask them?" There is also a design-round trap. The interviewer hands you a small-scale problem statement and waits to see whether you reflexively draw twelve boxes.

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, and CNCF found 42% of adopters consolidating. 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."

Likely follow-ups:

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 reflexively propose a rewrite in either direction. Reduce active harm 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 survivable. Then stop new splits until each one has an owner-team justification.

A red flag that fails candidates: treating "when not" as a trick question and answering "microservices are always the right long-term goal, you just need to get there gradually." Interviewers hear this as a decade-old default that has survived contact with none of the recent evidence.

5. TL;DR