Skip to main content

When Microservices Are Right -- and When They Absolutely Are Not

What This Concept Is​

This concept is the decision rule. Concept 10 described what microservices is; Concept 11 priced what it costs. This concept closes the cluster with the rules for when the style is genuinely the right answer -- and when it is a guaranteed mistake.

Signals that microservices are right​

All of these should be true, or nearly true:

  1. Many teams, large organization. You have (or are very soon going to have) 5+ teams that need to ship independently. Conway's law pushes the architecture toward team autonomy.
  2. Independent deployability is a hard requirement. Not "nice to have." Required by compliance (deploy windows per regulated subsystem), by SLA (zero-downtime deploys of one capability while another is being touched), or by team throughput.
  3. Different services have genuinely different scale or availability characteristics. The recommendation engine and the payment service have nothing to do with each other operationally.
  4. The domain is large and has clear bounded contexts. You can name 10+ bounded contexts without forcing it.
  5. You have platform capabilities built. Auth, logging, tracing, metrics, CI templates, service mesh or gateway, deploy automation. Building them while also extracting services is how projects fail.
  6. The team has distributed-systems experience. At least some members have shipped microservices before. The learning curve is steep.

If all six are true, microservices are a reasonable answer.

Signals that microservices are absolutely wrong​

Any one of these is enough to disqualify microservices:

  1. Small team. Under ~20 engineers, the platform tax dominates. Exceptions exist for serverless-heavy shops, but they are rare.
  2. Early-stage product. Requirements are volatile. Bounded contexts are not stable. Premature boundary commitment locks in the wrong decomposition. Fowler's "MonolithFirst" is the rule here.
  3. Domain is small or simple. CRUD on 20 tables does not need 15 services. It needs a layered app.
  4. Strong consistency is a pervasive requirement. Financial ledgers, stock inventory, reservations, regulated records -- microservices make these strictly harder.
  5. No platform team and no budget for one. Without shared auth/tracing/logging/metrics, the system will rot fast.
  6. The team is extracting because microservices is the goal. "We want to modernize" is not a requirement. If the benefit cannot be named as a specific pain that goes away, the cost has no target.

The anti-pattern catalog​

Specific bad situations worth naming:

  • Distributed monolith. Services that must deploy together. You paid the tax, got none of the benefit.
  • Microservices with shared database. You have service-based architecture with worse granularity. Merge services or ditch microservices.
  • Chatty microservices. Service A calls B calls C calls D to serve one request. Network tax multiplied. Merge services until the chattiness drops.
  • Nanoservices. One endpoint per service. Granularity below bounded context. Each service is overhead; total is a mess.
  • Microservices without observability. Every incident is an archaeology dig. Fix this first or go back to monolith.
  • Microservices without team ownership. A service owned by everyone is owned by no one. Attribute ownership before extraction.

Why It Matters Here​

The most common architecture failure in the industry is not "wrong style" but "microservices adopted by a team without the signals." This concept is the checklist that prevents that failure.

An architect who can name the disqualifiers (and hold the line when someone says "but it's modern") is more valuable than one who can diagram the topology perfectly.

Concrete Example​

Two real decisions​

Decision A: a 4-engineer startup proposing microservices for their MVP.

  • Team size: 4 (disqualifier 1)
  • Stage: pre-product-market fit (disqualifier 2)
  • Domain: 6-table SaaS CRUD (disqualifier 3)
  • Consistency: they need billing to be correct (disqualifier 4 leans against)
  • Platform: none (disqualifier 5)

Verdict: absolutely not. Modular monolith. Revisit at 20+ engineers and stable domain.

Decision B: a 150-engineer company with a 7-year-old monolith.

  • Team size: 150 across 18 teams (signal 1 ✓)
  • Deploy pain: 4-hour weekly release train; hotfixes block everyone (signal 2 ✓)
  • Scale: search and checkout have wildly different traffic shapes (signal 3 ✓)
  • Domain: 25 bounded contexts already mapped (signal 4 ✓)
  • Platform: they have CI/CD, partial tracing, need to build the rest (signal 5 ~)
  • Experience: 3 senior engineers have shipped microservices (signal 6 ✓)

Verdict: proceed, but via modular-monolith-then-extract (Concept 15), invest in platform first, start with 2 services, measure, iterate.

Counterexample: service-based is often the right answer​

A mid-size team (30-60 engineers) with a monolith in pain often does not need microservices. They need service-based (Concept 7): 4-8 services, shared DB, coarse granularity. Pays part of the tax for part of the benefit. Moves faster than microservices, solves most of the pain.

Common Confusion / Misconception​

"Microservices is the 'mature' architecture; we will grow into it." Growing into the wrong architecture is still wrong. Many successful companies run modular monoliths at very large scale (Shopify, StackOverflow, Basecamp). "Mature" is not microservices; "mature" is matching style to context.

"The anti-pattern list only applies to other teams." Most of those anti-patterns are not visible until you are in them. Build the tax ledger (Concept 11), the platform preconditions, and the ownership attribution before extraction, not after.

"If our monolith is hurting, microservices will fix it." If the pain is code quality, microservices will distribute the pain. If the pain is specifically deploy coupling or team autonomy, microservices may help -- after first trying modular monolith boundaries (Cluster 2), which are dramatically cheaper.

"Cloud and Kubernetes make this easier." They make the operational substrate easier. They do not change the list of signals or disqualifiers.

"Microservices and DDD go together." They can, but microservices without DDD (or equivalent bounded-context discipline) almost always produces wrong decomposition. This is why M03 (DDD) precedes heavy microservices work in the semester plan.

How To Use It​

Decision flow for any serious microservices proposal:

Practical default stance: say no by default, yes with evidence. This is the opposite of where most teams sit, which is "yes by default, proof of disqualification on request." Flipping that default saves years of pain.

Check Yourself​

  1. List the six positive signals and the six disqualifiers from memory.
  2. A team has three of the positive signals and two disqualifiers. What do you recommend?
  3. What is the difference between "microservices is the wrong choice" and "microservices is too early"? How do those recommendations differ operationally?

Mini Drill or Application​

Pick three real or realistic teams (you can use Decision A and B from above plus one of your own). For each, in 10 minutes:

  1. Score each of the 6 positive signals (yes / partial / no).
  2. Score each of the 6 disqualifiers (yes / no).
  3. Write the one-paragraph verdict.
  4. If the answer is "no, yet," write the precondition list.

Read This Only If Stuck​