Strong vs Eventual Consistency: Data Replication Tradeoff
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 ...