Part 7 · 1 chapters · ~8 min
Incident Log: The Distributed Monolith
A composite incident: services split by layer with a shared database and shared DTO library, lockstep release trains, a deserialisation outage, and the remediation: capability-based boundaries, versioned contracts, tolerant readers and independent deploys.
10
Timeline and lessons
A composite incident assembled from patterns widely reported in industry post-mortems and talks; names and numbers are illustrative.
| signal | what it means |
|---|---|
| services must deploy together | they are one deployable pretending to be several |
| a shared "models" or "common" library with domain types | coupling through code; one change breaks many |
| most features touch 3+ services | boundaries cut across capabilities |
| a shared database | coupling through data (next part) |
Tolerant reader: consumers ignore unknown fields and default missing optional ones, so producers can add fields without breaking anyone. Combined with additive-only contract changes, it removes the lockstep.
INCIDENT: THE DISTRIBUTED MONOLITH
twelve services that could only ship together
swipe the figure sideways, or tap expand for full screen
1/4
the split
The monolith was split by technical layer (API, business, data access) and by noun, so most features touched many services, and all shared one database and a shared models library.
split by layer, shared DB and DTOscoupling kept, network added