Cheat sheetCD-04

The Hard Parts

Core Design / The Hard Parts

The hard parts are trade-off analyses, not recipes: disintegrators vs integrators for service and data granularity, and the distributed data and transactions that decomposition forces you to confront.

01
DisintegratorsReasons to split: scope, volatility, scalability, fault tolerance, security, differing data/access.
02
IntegratorsReasons to keep together: database transactions, data dependencies, workflow/choreography cost.
03
Data decompositionSplit a shared DB only when disintegrators outweigh data relationships and consistency needs.
04
Distributed data/txnsSplitting raises data ownership; ACID gives way to eventual consistency via sagas.
⚑

Never chase smallness. List the disintegrator forces pushing a service or database apart and the integrator forces holding it together, then decide which dominate for this context. When a split breaks an ACID transaction, replace it with a saga and eventual consistency, and settle data ownership so coupling does not just move into runtime calls.

Split under tensionFraud Detection's volatility and scaling (disintegrators) beat a shared transaction (integrator) once eventual consistency is acceptable.
Trade-off paid knowinglyThe lost ACID order+fraud transaction becomes a saga, accepting a bounded inconsistency window for independent scaling.
disintegrators => split (scope, volatility, scale, fault, security)
integrators => keep (transactions, data deps, workflow)
right-size = balance forces, not maximize smallness
split DB => data ownership + remote reads
cross-service txn => saga + eventual consistency (no ACID)
hard-partsgranularitydisintegratorsintegratorsdistributed-datatrade-offs
review in 6d