Microservices Decomposition Clinic

Retrieval Prompts

1. Name the six positive signals and the six disqualifiers for microservices.
2. State the six taxes of microservices with one concrete example of each.
3. Define bounded context in one sentence and explain why it is the right sizing unit for a microservice.
4. State the strangler fig pattern and when to use it.
5. Name four anti-patterns: distributed monolith, shared-database microservices, chatty microservices, nanoservices. Give the tell of each.

Compare and Distinguish

• bounded context vs team boundary -- they often align; when should they not?
• service with own schema on shared DB server vs service with own DB cluster -- the difference in tax.
• extract-first vs platform-first -- which goes first and why?
• orchestration (mediator) vs choreography (broker) across services -- both are async; how do you pick?
• saga vs distributed transaction -- one is the only realistic choice in microservices; why?

Common Mistake Check

For each scenario, identify the anti-pattern in 2-3 sentences and prescribe the fix:

1. "Our 12 microservices each have their own schema, but they all live in the same Postgres cluster and freely join across schemas in reports."
2. "Every deploy to the order-service requires a coordinated deploy to the customer-service and the billing-service."
3. "A request to view a single order touches 9 services."
4. "We have 40 services; each one exposes 1-2 endpoints."
5. "Our observability story is 'we tail logs from 18 hosts in tmux.'"
6. "We extracted 6 services but have no platform team. The CI pipelines were copy-pasted from the monolith."

Mini Application

You are the architect for the following system and have been asked to produce a decomposition plan.

The brief. OrderFlow: 7-year-old commerce platform, Rails monolith, ~350k LOC, 25 teams (~150 engineers), weekly deploy train. Top pain points, in order:

1. Every deploy blocks all teams for hours.
2. The recommendations subsystem is slow and over-uses CPU; it affects unrelated endpoints.
3. The internationalization effort requires three teams editing the same files.
4. The payment subsystem is audited quarterly and must support fine-grained change control.
5. Onboarding a new engineer takes 8 weeks.

Existing bounded contexts (from a prior M03 exercise, assume stable):

catalog, pricing, inventory, checkout, payments, fraud, fulfillment, shipping, notifications, loyalty, returns, billing, accounts, search, recommendations, analytics, i18n, admin.

Step 1 -- Qualification (10 min)

Run the 6 positive signals and 6 disqualifiers (Concept 12). Score each. Verdict: go / defer / no.

Step 2 -- Tax ledger (20 min)

Fill the 6-row tax ledger (Concept 11) with concrete estimated numbers:

Tax	Estimated cost	Mitigation plan
Network
Debugging
Deploy
Data
Consistency
People

Step 3 -- First extractions (20 min)

Choose up to 3 services to extract first. For each:

• Which pain point does it address?
• Why is it an easier extraction than the others?
• What is the minimum platform capability needed before this extraction?
• What is the rollback plan if it does not deliver independent deploy after 2 quarters?

Step 4 -- Not-extractions (10 min)

Name 3 capabilities that will stay in the monolith and defend why. Examples to consider: admin, analytics, internal reporting, legacy glue.

Step 5 -- Decision record (15 min)

Produce a one-page ADR in this format:

# ADR: Microservices-style extraction for OrderFlow

## Status
Proposed

## Context
...

## Decision
...

## Consequences
Positive:
- ...
Negative / tax:
- ...

## Alternatives considered
- Service-based architecture: ...
- Stay modular monolith: ...

## First steps (90 days)
1. ...
2. ...
3. ...

Evidence Check

• Your verdict in Step 1 names which signals and disqualifiers drove it.
• Your tax ledger has a concrete number or phrase in every cell, not "TBD."
• Your first-extraction choices are defended against reasonable alternatives.
• Your not-extractions include at least one non-obvious "keep in monolith."
• Your ADR is self-contained and could survive review by another architect.

Page is complete only if the ADR can stand on its own without your narration.