Designing Data Consistency Patterns

1. Understanding Strong Consistency

Aspect	Detail
Guarantee	Read returns latest committed write
Implementation	Single leader, sync replication, consensus
Cost	Higher latency; lower availability under partition
Use cases	Inventory, money, locks
Systems	Spanner, etcd, ZooKeeper, RDBMS

Aspect	Detail
Guarantee	Replicas converge given no further writes
Window	ms–seconds typically
Conflict resolution	LWW, vector clocks, CRDTs
Systems	Cassandra, DynamoDB, S3, DNS

Technique	Description
Sticky sessions	Route user to same node
Read-from-primary window	For N seconds after a write
Token-based	Send last write timestamp; replica waits
Local cache update	Reflect own write immediately

Issue	Solution
Going back in time	Sticky session to one replica
Min-version token	Reject reads older than seen

Mechanism	Description
Per-session ordering	Same client's writes applied in order
Sequence numbers	Append seq id; replicas enforce order
Single connection	Serialize at conn level

Concept	Detail
Definition	If A happens-before B, all clients see A before B
Implementation	Vector clocks / dependency tracking
Use cases	Comment threads, social timelines
Systems	COPS, MongoDB causal sessions

Property	Detail
Scope	Within a single client session
Includes	Read-your-writes + monotonic reads + monotonic writes
Use case	Practical for user-facing apps with weak global consistency

Bound	Description
Time-bounded	"Up to 5 sec stale"
Version-bounded	"At most K versions behind"
Use cases	Cosmos DB, dashboards, analytics

Strategy	Description
Last-Write-Wins (LWW)	Pick latest timestamp; loses data
Application-defined merge	Custom function (e.g., shopping cart union)
CRDTs	Mathematically conflict-free
Multi-value	Return all conflicting versions to client
Operational transform	Collaborative editing (Google Docs)

UPDATE accounts
   SET balance = 100, version = version + 1
 WHERE id = 1 AND version = 7;
-- 0 rows affected → conflict; reload + retry

Mechanism	Use
Version column	Detect concurrent modification
ETag (HTTP)	If-Match header for REST
CAS (Compare-and-Swap)	Redis WATCH/MULTI, DynamoDB conditions
Best for	Low-contention workloads

Mechanism	SQL
Row lock	`SELECT ... FOR UPDATE`
Skip locked	`FOR UPDATE SKIP LOCKED` (job queues)
Advisory locks	`pg_advisory_lock(key)`
Distributed lock	Redis Redlock, ZK ephemeral nodes

Warning: Hold locks briefly. Always set timeouts to avoid deadlocks/blocking.