Cap-Theorem

Overview Strong and eventual consistency describe how distributed systems handle replicated data after a write. Strong consistency guarantees every read reflects the latest write by blocking until replicas agree, while eventual consistency returns immediately and lets replicas converge in the background. The choice trades write latency and availability against read freshness. Comparison Diagram Strong ConsistencyEventual ConsistencyClientPrimaryReplica 1Replica 2write blocks untilall replicas ackAny read, any replica,always returns latest valueClientNodeReplica 1Replica 2ACK immediateasync, delayedRead from Replica 1 mayreturn stale value until t+Δ Comparison Table Aspect Strong Consistency Eventual Consistency Write acknowledgment Ack returned only after write is durably applied to all (or a quorum of) replicas Ack returned as soon as the write hits the local/primary node Replication propagation Synchronous — write blocks until replicas confirm Asynchronous — replication happens in the background Read guarantee Every read reflects the most recent write (linearizable) Reads may return stale data until replicas converge Conflict handling Prevented upfront via consensus/locking that serializes writes Resolved after the fact via LWW, vector clocks, or CRDTs Write latency Higher — pays network round-trip cost to replicas/quorum Lower — commits locally before propagating Behavior under partition Unavailable or degraded if quorum can’t be reached (CP) Stays available, serving from whichever replica is reachable (AP) Typical mechanism Consensus protocols like Paxos/Raft, synchronous quorum writes Gossip protocols, anti-entropy repair, background sync Typical use cases Banking ledgers, inventory counts, leader election Social feeds, DNS, shopping carts, CDN caches Key Differences Strong consistency blocks the write until a quorum confirms; eventual consistency acks after a local commit. This is the classic CAP tradeoff: strong favors consistency during a partition, eventual favors availability. Strong relies on consensus protocols like Raft; eventual relies on background anti-entropy repair. Only strong consistency guarantees read-after-write; eventual consistency allows a stale-read window. When to Use Each Strong Consistency ...

Overview When a distributed system suffers a network partition, it must choose between consistency (every node sees the same data, even if that means rejecting requests) and availability (every request gets a response, even if the data might be stale). This CAP theorem tradeoff shapes how databases behave under failure and directly affects correctness guarantees versus uptime. Comparison Diagram Consistency (CP)Availability (AP)ClientClient503 blocked200 OK (stale)Node ANode BpartitionNode ANode BpartitionWaits for quorum, rejects requestGuarantee: no stale readsAnswers immediately from local dataGuarantee: no downtime Comparison Table Aspect Consistency (CP) Availability (AP) Normal operation (no partition) Behaves identically to any healthy cluster; all replicas agree Behaves identically to any healthy cluster; all replicas agree Behavior when a partition occurs Nodes that cannot confirm quorum stop responding All nodes keep responding regardless of quorum status Write handling during partition Writes are rejected or queued until enough replicas are reachable Writes are accepted locally and replicated once the partition heals Read handling during partition Reads are blocked or errored if the latest value can’t be confirmed Reads are served from whatever local replica is reachable, even if stale Client-facing failure mode Client sees a timeout or explicit error (e.g. 503) Client sees a successful response that may contain outdated data Data guarantee provided Linearizability - no two nodes ever disagree on current state Liveness - the system always answers, correctness may lag Recovery after partition heals Resumes cleanly; no conflicting writes existed since they were blocked Must reconcile diverging writes via vector clocks, LWW, or CRDTs Representative systems HBase, Zookeeper, MongoDB (default majority writes) Cassandra, DynamoDB, Riak Key Differences The tradeoff only bites during an actual network partition - outside of that, both behave the same. Consistency requires a quorum agreement before answering, which can mean refusing requests. Availability guarantees a response but risks returning stale data to the client. The choice determines whether you need a conflict resolution strategy for divergent writes after recovery. Many production databases offer tunable consistency, letting you pick per-operation rather than a single global stance. When to Use Each Consistency (CP) ...