ARC 6Prove Boundaries and DeliverChapters 23–26
Chapter 25 — Identify State That Does Not Fit DSM
Chapter objective: After this chapter, a developer can select technology from business invariants, failure consequences, and evidence requirements without defaulting to DSM because a problem is low-latency, distributed, or "shared."
Learning objectives
- Decide whether state is repairable before discussing collection type.
- Distinguish system of record, cache, history log, consensus coordination, and DSM.
- Write a reviewable reason for adopting or rejecting DSM.
- Detect dual-write, unbounded-state, and unobservable-repair anti-patterns.
Prerequisites
- All three collections, partition boundaries, capacity, and federation are complete.
- Business consequences of loss, duplicate, reordering, and divergence can be stated.
- "Do not use DSM" is accepted as a successful design conclusion.
Case progress
The fulfillment team reviews orders, inventory deductions, route hints, shard owners, request counters, and audit events again. The goal is correct ownership of each state rather than larger DSM coverage.
Eliminate unsuitable responsibilities before choosing a collection
| Requirement | Primary responsibility | Why DSM is not primary |
|---|---|---|
| authoritative order/balance/inventory fact | transactional database or fact service | confirmed transactions cannot be rewritten by eventual convergence |
| complete replayable history | event log or streaming platform | DSM centers on current coordination state, not complete history |
| linearized configuration, election, or strong CAS | consensus coordination service | DSM can permit local success during a partition |
| low-latency read rebuilt from a fact source | cache | no need for domain merge, repair, and protocol identity |
| small, repairable coordination state with clear semantics | DSM candidate | Register, Lease, or CRDT may express the invariant |
A candidate still needs bounded size, TTL/cleanup, schema evolution, observable failure, repair cost, security, capacity, and operating ownership.
Three direct rejection signals
- DSM and database both write authority: dual write without one authority and compensation adds another divergence layer.
- Unbounded state growth: full order history, logs, or analytical details make lifecycle and memory capacity uncontrollable.
- Unexplained failure window: "eventual consistency" does not answer two OK responses, old tokens, missed deltas, or slow consumers.
Final boundary of the running case
route-hints: Register candidate; health/service management remains authoritative.shard-owners: Lease candidate; external writes validate fencing tokens.request-counter: PN-Counter candidate for mergeable observation, not settlement.- Orders and inventory: DSM rejected as system of record.
- Audit events: immutable history system, not ChangeStream alone.
Counterexample and fault injection
- Store inventory balance in a Register, create partitioned writes, and observe that the eventual winner loses a business deduction.
- Treat ChangeStream as audit history, overflow it, and compare event loss with completeness requirements.
- Treat a CRDT counter as a bill and identify source duplication, reversal, and legal-record gaps.
- Add a custom resolver for pure cache data and compare its complexity with rebuilding from authority.
Experiment
npm test -- --test-name-pattern="phase 6 assets"In technology-selection-review.json, record invariant,
failure cost, source of truth, decision, and counterfactual condition
for eight state categories.
Experiment acceptance card
| Field | Content |
|---|---|
| Command | Book static decision-asset test |
| Input or fault | fact, history, strong coordination, cache, and repairable coordination state |
| Observable result | every item has an adoption/rejection reason and a condition that would change the decision |
| Evidence level | E1: design review combined later with target-system runtime evidence |
| This experiment does not prove | That an alternative product meets SLA, security, cost, or team capability |
Review
- Repairability is evaluated before collection type.
- DSM does not own order facts, complete history, or global linearizability.
- Rebuildable low-latency reads start as a cache question; multiple instances alone do not justify a consistency framework.
- Rejection receives the same reproducible reasoning as adoption.
Next
Chapter 26 combines the method into an executable fulfillment control plane with faults, observation, and explicit boundaries.