Skip to content

Strong vs Eventual Consistency

1. Decision

Choose Strong Consistency (Linearizability) for financial ledgers, user inventory reservations, and authentication authorization where stale reads or conflicting concurrent updates are unacceptable; choose Eventual Consistency for high-availability, low-latency global applications (social media feeds, product reviews, view counters) where transient data staleness is acceptable in exchange for high write throughput and partition tolerance.

2. 30-Second Answer

Consistency models define the visibility order of data writes across distributed nodes. Strong Consistency (Linearizability) guarantees that once a write completes, every subsequent read across any node in the system will instantly return the new value (or a newer one). It enforces a single global time-ordered view of data, but incurs higher write latency (synchronous replication/consensus) and sacrifices availability during network partitions (CP in CAP theorem). Eventual Consistency guarantees that if no new updates are made, all replicas will eventually converge to the same value over time. It delivers ultra-low write latency and high availability (AP in CAP theorem), but clients may read stale data during the convergence window.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
Strong Consistency (Linearizability / Sequential) Financial bank accounts, double-entry bookkeeping, seat reservations, user authentication state High-velocity global traffic requiring sub-millisecond writes, multi-region active-active writes Medium to High (Synchronous replication / Paxos / Raft consensus round-trips) Bounded by synchronous consensus coordination overhead Strong (Single global order; zero stale reads) Medium to High
Eventual Consistency (BASE Model) Social media likes/comments, video view counts, product reviews, DNS records, global CDN caching Financial balances, inventory stock reservation, authorization permissions Low (Asynchronous write execution; microsecond local writes) Extremely High (Scales linearly across global nodes without locks) Eventual (Stale read window until replication catches up) Low to Medium

4. Selection Rules

Requirement Best Choice Rationale / Example
Bank Account Balance Transfer Strong Consistency Prevents double-spending by guaranteeing immediate visibility across all transactions
YouTube Video View Counter Eventual Consistency Transiently showing 10,000 vs 10,050 views has zero business impact
E-Commerce Inventory Reservation Gate Strong Consistency Prevents overselling limited stock during flash sales
Global Social Media Status Feed Eventual Consistency Friends seeing a post 2 seconds later is acceptable for high-volume feed scale
CAP Theorem: Maximize Availability During Outage Eventual Consistency (AP) Accepts local writes on all available partitions during network splits

5. Tradeoffs

  1. Immediate Data Freshness vs Ultra-Low Write Latency
  2. Gain (Strong): Guarantees clients never read outdated state.
  3. Lose (Strong): Writes must wait for synchronous replica acknowledgments or consensus rounds.
  4. CP System (Consistency/Partition Tolerance) vs AP System (Availability/Partition Tolerance)
  5. Gain (Strong / CP): Rejects writes on minority partitions during network splits to prevent data divergence.
  6. Lose (Strong / CP): System becomes unavailable for writes during network partitions.
  7. Linear Scale-Out vs Consensus Coordination Overhead
  8. Gain (Eventual): Write throughput scales linearly by adding nodes without locking network coordination.
  9. Lose (Eventual): Requires conflict resolution mechanisms (Last-Writer-Wins, CRDTs, Vector Clocks).
  10. Simple Application Mental Model vs Stale Read Handling
  11. Gain (Strong): Application code reads/writes like a local single-node database.
  12. Lose (Strong): Poor performance across geographically distributed multi-region data centers.
  13. Causal Consistency vs Pure Eventual Consistency
  14. Gain (Causal): Guarantees cause-and-effect operations are observed in order (e.g., question before answer).
  15. Lose (Causal): Slightly higher metadata tracking overhead (Vector Clocks) than pure eventual consistency.

6. Interview Counter Questions

  1. What is the difference between Linearizability and Serializability?
  2. How does the CAP Theorem dictate the choice between Strong Consistency (CP) and Eventual Consistency (AP)?
  3. How do you implement Causal Consistency using Vector Clocks or Lamport Timestamps?
  4. What is the PACELC Theorem and how does it extend the CAP Theorem?
  5. How do Quorum Reads and Writes (\(R + W > N\)) achieve Strong Consistency in distributed systems?
  6. How does Read-Your-Own-Writes consistency bridge the gap between Strong and Eventual Consistency?
  7. What are Conflict-Free Replicated Data Types (CRDTs) and how do they resolve eventual consistency conflicts?
  8. How does Google Spanner achieve global Strong Consistency without massive lock latency?
  9. What is Monotonic Read Consistency and why is it important for user experience?
  10. How do you handle conflict resolution in an Eventual Consistency system when two users edit data simultaneously?

7. Gold Standard Answers

  1. Linearizability: A real-time freshness guarantee on a single object (reads return the latest written value globally). Serializability: A multi-operation transactional guarantee on multiple objects (transactions execute as if in some serial order). Strict Serializability combines both.
  2. During a network partition (P), a distributed system MUST choose between: (1) Rejecting writes to preserve Consistency (CP), or (2) Accepting writes on all nodes, sacrificing Consistency for Availability (AP).
  3. Vector Clocks track logical timestamps per node [NodeA:1, NodeB:2]. By comparing vector arrays, systems determine if Event A causally preceded Event B, or if they were concurrent conflicts requiring resolution.
  4. PACELC states: If there is a Partition (P), trade off Availability (A) vs Consistency (C); Else (E), trade off Latency (L) vs Consistency (C). Explains system tradeoffs under normal operating conditions.
  5. In an \(N\)-replica system, set Read Quorum (\(R\)) + Write Quorum (\(W\)) \(> N\). Overlapping nodes guarantee that any read quorum intersects with at least one node containing the latest write quorum update.
  6. Read-Your-Own-Writes guarantees a client always sees their own updates immediately. Implement by routing a user's reads to the Primary node for 5 seconds after they write, while other users read from eventual replicas.
  7. CRDTs are data structures (e.g. PN-Counters, LWW-Element-Set) engineered so that concurrent updates on multiple nodes can be merged deterministically without coordination, guaranteeing eventual convergence.
  8. Spanner uses TrueTime API backed by hardware atomic clocks and GPS receivers in every datacenter. TrueTime provides a tight time uncertainty bound (\(\epsilon \le 7\text{ms}\)), enabling global External Consistency using Paxos without cross-region locks.
  9. Monotonic Reads guarantees that once a user sees a data state, they will never see an older state on subsequent reads (prevents time-travel data regression when reading across multiple lagging replicas).
  10. Conflict resolution strategies: (1) Last-Writer-Wins (LWW - overwrite based on timestamp), (2) Application-level merge (present both versions to user, e.g. Git merge), (3) CRDT automatic convergence.

8. Common Mistakes

  • Assuming "Eventual Consistency" means data is never consistent, or using it for core financial balances.
  • Confusing Linearizability (single-key real-time freshness) with Serializability (multi-key transaction isolation).
  • Expecting Strong Consistency across global multi-region active-active datacenters without paying massive latency penalties.
  • Relying on Last-Writer-Wins (LWW) conflict resolution without synchronized NTP/atomic clocks, causing silent data loss due to clock drift.
  • Ignoring PACELC Theorem and focusing only on failure states (CAP), neglecting latency tradeoffs during normal operations.

9. Keywords

Strong Consistency, Eventual Consistency, Linearizability, Serializability, CAP Theorem, PACELC Theorem, Vector Clocks, Lamport Timestamps, Quorum (\(R+W>N\)), Read-Your-Own-Writes, CRDTs, Monotonic Reads, Last-Writer-Wins (LWW), TrueTime, Spanner.

10. Cheat Sheet

  • Strong Consistency (Linearizability): Real-time global freshness guarantee (CP). Writes wait for synchronous replica ACKs/consensus. Use for Money, Inventory, Auth.
  • Eventual Consistency (BASE): Fast microsecond local writes, background convergence (AP). Use for Views, Likes, Social Feeds, Product Reviews.
  • PACELC Rule: If Partitioned \(\rightarrow\) AP vs CP; Else \(\rightarrow\) Latency vs Consistency.
  • Quorum Formula: Set \(R + W > N\) (e.g., \(N=3, W=2, R=2\)) for Strong Consistency in leaderless/quorum systems.
  • User Experience Fix: Use Read-Your-Own-Writes to prevent users from seeing stale data after submitting a form.
  • Conflict Resolution: Last-Writer-Wins (LWW), CRDTs (automatic merge), or Application-level manual merge.

11. Related Decisions