How many deployables? Are boundaries enforced? Two separate dials.
Add boundaries first (1), then split along them (2). Split a tangle and you get a distributed monolith, the network costs with none of the independence.
What does splitting buy?
Bad: Less CPU
Assume search goes 10×: 15 monolith copies or 24 pods, both ≈ 60 vCPU.
Good: Teams ship alone
Each team deploys and rolls back alone, with its own backlog and on-call.
Every split sends three bills
- Network: ≈ 0.5–1 ms a hop, and it can fail
- Data: no cross-service transactions, so sagas and compensations
- Platform: pipelines, discovery, tracing, all before any feature
7.2 h
of failure a month: ten hops at 99.9%
One service fails 43 minutes a month. Ten in a row, failing independently: 0.999¹⁰ ≈ 99.0%. So keep synchronous chains to two or three hops.
When are those bills worth paying?
It’s about teams
When many teams change one system. Conversations among n people grow as n(n − 1)/2: 150 people, 11,175. Services with one owner swap most for API contracts.
A food delivery app: four or five services, not forty
Modules own their tables. Only parts with a reason leave: payments for compliance, rider pings as a write firehose, notifications behind a queue.
When is starting with services right?
- Replacing a well-understood system
- Several teams from day one, who’ve run microservices
- One part with radically different needs: a GPU-heavy transcoder
- Even then: a monolith plus a few services
The interview line
Start with a modular monolith. Pull out a few coarse services, each with a reason and its own data.