27.10 When should you split?

Deciding

In the restaurant: A small restaurant with three cooks doesn't need a food court. But when there are forty cooks, ten menus and constant collisions, splitting into stations, and later into stalls, starts to pay off.

In the system: Split for organisational and operational reasons you can name, not because microservices are fashionable.

Good reasons to extract a service:

• Team scaling: many teams blocking each other in one deploy pipeline. (The bookstore at 60 engineers, not at 5.)
• Different scaling needs: search needs 50 machines at peak; the rest needs 5.
• Different reliability or security needs: payments needs strict isolation, audits and its own release process.
• Different technology: recommendations needs a Python ML stack; the rest is Java.
• Fault isolation: a crash-prone feature shouldn't take down checkout.

Bad reasons:

• "Microservices are best practice."
• "Our monolith's code is messy" (fix the modules first; a messy monolith becomes messy services plus network calls).
• "We might need to scale someday."

How to split safely:

1. Start with a (modular) monolith. Martin Fowler's "MonolithFirst" argument: boundaries are easier to find once the domain is understood.
2. Enforce module boundaries inside the monolith first (27.3).
3. Extract one service at a time, starting with a well-bounded, high-value candidate (payments, search). Use the strangler fig pattern: route some traffic to the new service, grow it, retire the old code.
4. Have the platform ready: CI/CD per service, observability and tracing, service discovery, and on-call ownership.
5. Measure: deploy frequency, lead time, incidents. If they don't improve, rethink.

In interviews, the strongest answer is rarely "microservices" or "monolith". It's "a modular monolith, with these one or two services split out, for these reasons".

Memory code: "Split for teams and needs you can name, one stall at a time."

---