transactions-consistency

Think Through Transactions & Consistency

Overview

Production guidance for correctness under concurrency and distribution. Each reference paper captures the hazards that pass code review silently: isolation levels that do not mean what their names claim, dual writes that corrupt state, idempotency keys without fingerprints, locks without fencing, and retries that duplicate committed effects.

Core principle: Every invariant needs an enforcement point at an authoritative boundary. A local transaction never makes a remote side effect atomic, and a timeout never proves a rollback.

Domain Law

NO CONCURRENCY OR CONSISTENCY CHANGE WITHOUT:
1. the minimum required primary paper(s) for the mechanism selected from the context table;
2. the invariant, its authoritative owner, and all concurrent writers
   named before choosing a control;
3. the paper's pre-change questions
   answered, or each open point labeled as an assumption;
4. every applicable MUST mapped to an enforcement point, a test that
   forces the interleaving, or a documented exception.

When to Use

Use this skill when thinking through, reviewing, changing, or verifying:

• transaction boundaries, isolation levels, deadlocks, and retry scopes;
• optimistic locking, version columns, compare-and-swap, conditional updates;
• pessimistic locking, advisory locks, mutex/semaphore usage;
• entity state machines, legal transitions, and transition history;
• idempotency keys, request fingerprinting, response replay, dedup scope;
• sagas, compensation, and cross-service workflow consistency;
• consistency model selection (read-committed through serializable, eventual);
• replication topology and read semantics;
• partitioning/sharding keys, resharding, and hot-partition behavior;
• consensus-backed stores and leader election assumptions;
• distributed locks, leases, and fencing tokens;
• ordering guarantees and their scope.

When Not to Use

• Queue/job delivery semantics and the outbox pattern: use async-messaging (043, 047).
• Retry budgets, timeouts, circuit breakers: use resilience-flow-control (052, 053, 054).
• Schema constraints and index design: use data-storage (022, 027).
• Whole-system architecture and boundary decisions: use system-architecture-harness.