Managing Data Consistency

1. Understanding Eventual Consistency

Property	Detail
Definition	Replicas converge given no new writes
Convergence window	Milliseconds–seconds typical
Trade-off	Availability over immediate consistency
Use	Most cross-service reads

Mechanism	Detail
Single-writer DB	All writes through one node
Quorum reads/writes	R + W > N (Cassandra LOCAL_QUORUM)
Linearizability	etcd, Spanner, FoundationDB
Cost	Higher latency, lower availability

Concept	Detail
Definition	Causally related writes seen in order
Mechanism	Vector clocks / dependency tags
Use	Comments-on-posts, chat threads

Technique	Detail
Sticky session	Pin user to primary for short window
Read from primary	For just-written records
Pass write timestamp	Read replica waits for catch-up
Client cache	Display optimistic value

UPDATE orders
   SET status = 'PAID', version = version + 1
 WHERE id = $1 AND version = $2;
-- 0 rows affected → conflict; reload & retry

Mechanism	Detail
SELECT FOR UPDATE	Row lock until tx commits
Distributed lock	Redis Redlock, Zookeeper
Use	High contention, short critical sections
Risk	Deadlocks, throughput loss

Pattern	Detail
Idempotency-Key header	Server caches result by key
Upsert	`INSERT ... ON CONFLICT DO NOTHING`
State machine guard	Re-applying same transition is no-op

Strategy	Detail
Last-Write-Wins	Use HLC/wall clock; loses data
Custom merge	App-specific business rules
CRDTs	Mathematically merge-able types (G-Counter, OR-Set)
Manual	Surface to user (e.g. doc collaboration)

Approach	Detail
Integer version	Increment per update
ETag / hash	Content-derived
Timestamp	HLC preferred over wall clock
History table	Audit + temporal queries