Consistency and Transactions
Consistency is not one switch for the entire system.Different operations accept different staleness or coordination costs — articulate them operation by operation in design documents.
Strong Versus Eventual
Section titled “Strong Versus Eventual”Strong (linearizable-ish) behavior: reads after a successful write observe that write.Eventual: replicas or caches may temporarily lag.Choose strong where money, inventory correctness, or safety depends on freshest state; eventual where product tolerates seconds of lag behind an authority.
See requirements and database replication docs: RDBMS reliability.
Coordinating Across Services
Section titled “Coordinating Across Services”Two-phase commit coordinates distributed participants with blocking locks — simple conceptually but fragile at scale (availability under partitions, long-holding locks). Sagas model long-running work as local transactions plus compensating actions when a later step fails. They trade immediate global consistency for explicit failure stories you can reason about in code.
Idempotency
Section titled “Idempotency”At-least-once delivery (queues, RPC retries) means duplicate processing is normal.Idempotent handlers keyed by business id or idempotency token prevent double effects.
Optimistic Locking
Section titled “Optimistic Locking”Optimistic locking (version column or ETag) detects concurrent updates at commit time. Strong when conflicts are rare; poor when many writers fight for the same row — then consider domain-level partitioning or queues to serialize conflict.
CAP and PACELC
Section titled “CAP and PACELC”CAP reminds you that under network partition you cannot have both strong linearizability and full availability without compromise.PACELC extends: when the system is not partitioned, you still trade latency against consistency.
Do not answer “we picked AP” once for the architecture — tie guarantees to APIs and paths.
Related: Write scaling, Fault tolerance, glossary (CAP, PACELC, 2PC).