Chapter 9 — Choose Collections from Business Invariants
Chapter objective: After this chapter, a developer can begin with a business invariant and give a falsifiable, testable reason for choosing Register, Lease, CRDT, or a different system of record.
Learning objectives
- Decide whether state fits DSM before selecting a collection.
- Map an invariant to collection semantics and a failure boundary.
- Define a minimal validation experiment for each decision.
- Recognize state that belongs in a database or messaging system.
Prerequisites
- The three collection experiments in Chapters 5–8 are complete.
- Local success, remote visibility, and eventual convergence are distinct concepts.
Case progress
The team reviews the route hint, shard owner, and request counter separately. Each decision records adoption conditions, failure behavior, and rejection reasons. DSM is not assumed to fit every state.
Decision order
The first question asks whether lost state can be repaired from a peer or rebuilt from an authoritative source. When it cannot, or when local success immediately creates an irreversible commitment, the state stays in a transactional or event-based system of record.
| State | Key invariant | Choice | Partition window | Validation focus |
|---|---|---|---|---|
| route hint | one current visible hint per key | Register | the two sides may differ briefly | deterministic convergence and stale fallback |
| shard owner | time-bounded ownership; old owner cannot write | Lease | the old holder may still run | fencing rejects the old token after transfer |
| request counter | local updates merge safely | CRDT | a local count is incomplete | duplicate, reordered, and regrouped merges agree |
| order/payment | transactional fact and audit history | keep outside DSM as primary storage | two successes can be irreversible | transaction, idempotency, reconciliation, and audit |
A choice is a testable hypothesis
"Lease supports ownership" does not complete a decision. A stronger version is:
For
orders-17, only the worker holding the newest fencing token can commit scheduling results. After transfer, the executor rejects the old token. A transfer test and an old-token counterexample validate the rule.
This statement identifies the actor, state, failure window, external responsibility, and evidence.
Counterexample and fault injection
- A Register can identify a newer shard owner but supplies no TTL, renewal, transfer, or fencing contract.
- A Lease for request totals forces all updates through one owner and discards local-write availability.
- A CRDT for order state does not establish legal state transitions, cross-resource transactions, or audit history.
Experiment
Open collection-review.json and fill in
decision, invariant,
failureWindow, and evidenceCommand for every
scenario. Then run:
node --test tests/chapter-assets.test.mjsThe reference answer expects a business reason for each adoption and rejection, not only a collection name.
Experiment acceptance card
| Field | Content |
|---|---|
| Command | node --test tests/chapter-assets.test.mjs |
| Input or fault | Seven business states with invariants and failure windows |
| Observable result | All three DSM collection types and the rejected cases are covered; required fields are present |
| Evidence level | E1: design-review asset check backed by E2/E3 experiments from preceding chapters |
| This experiment does not prove | Automatic fit for a new domain, production capacity, or organizational acceptance |
Review
- DSM suitability is decided before a collection type.
- Register covers current values, Lease covers time-bounded ownership, and CRDT covers mergeable local updates.
- Every decision records a failure window and a validation command.
- Orders, inventory, and payments remain with transactional systems of record.
Next
Chapter 10 begins Arc 3 by identifying who belongs to the cluster and who is only suspected of being offline before discussing delta and repair.