Where consistency stops
In an event driven system you cannot make everything strongly consistent. The skill is choosing a consistency boundary, a unit that stays internally consistent, while everything across the boundary is only eventually consistent.
The aggregate as the boundary
A common boundary is the aggregate, a cluster of objects treated as one for changes. Inside one aggregate a command applies atomically with its invariants enforced. Between aggregates, coordination happens through events and is eventual.
- Inside the boundary. Enforce invariants now, in one transaction.
- Across the boundary. Accept lag and reconcile through events and sagas.
Designing the lines
- Keep an invariant that must hold instantly inside a single boundary.
- If two pieces of data must always agree at once, they probably belong in the same aggregate.
- If they can disagree briefly, split them and connect with events.
Why it matters
Putting too much in one boundary creates contention and hurts availability. Splitting things that share a hard invariant leads to violations that events cannot repair.
Key idea
Choose consistency boundaries so each holds its invariants atomically, and let everything across the boundary be eventually consistent through events.