CAP, consensus, replication, partitioning
Every read gets most recent write
Zookeeper, HBase, SpannerEvery request gets a response
Cassandra, DynamoDB, CouchDBSystem works despite network splits
Required in distributed systemsDuring a network partition, choose either CP (consistent but some requests fail) or AP (available but stale reads).
Leader election + log replication. Understandable. etcd, CockroachDB
Theoretical foundation. Complex. Google Chubby
Zookeeper Atomic Broadcast. Leader-based. Zookeeper
One writer, N readers. Simple. PostgreSQL streaming replication
Multiple writers. Conflict resolution needed. CRDTs
Quorum reads/writes (R+W>N). Cassandra, DynamoDB
Consistent hashing. Even distribution. No range queries
Sorted ranges. Good for scans. Hotspot risk
Lookup table for routing. Flexible. Single point of failure
Linearizable. All reads see latest write. Spanner
Converges over time. DynamoDB, Cassandra
Respects causality. Vector clocks. COPS
User sees their own writes. Session consistency
Logical counter. Incremented on send/receive. Total order but not causal.
Array of counters per node. Detects causality and conflicts. [A:2, B:3, C:1]
Physical time + logical counter. CockroachDB. Bounded clock skew.
Distributed transactions via compensating actions. Choreography vs Orchestration.
Cross-service transactionsStore events, not state. Rebuild state by replaying. Append-only log.
Audit trails, undoSeparate read/write models. Optimized independently.
Complex domains, high read loadFail fast when downstream is unhealthy. Closed → Open → Half-Open.
Fault toleranceProxy alongside each service. mTLS, observability, retry.
Service mesh (Istio, Envoy)Isolate failures. Separate thread pools / connection pools per dependency.
Resilience