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

  1. Decide whether state is repairable before discussing collection type.
  2. Distinguish system of record, cache, history log, consensus coordination, and DSM.
  3. Write a reviewable reason for adopting or rejecting DSM.
  4. 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

Decision tree for excluding unsuitable DSM state

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

  1. DSM and database both write authority: dual write without one authority and compensation adds another divergence layer.
  2. Unbounded state growth: full order history, logs, or analytical details make lifecycle and memory capacity uncontrollable.
  3. 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.