Questions: Eventual Consistency

Question 1

Two users in different data centers simultaneously update the same record under an eventually consistent system. User A adds an item; User B removes a different item. A network partition then isolates the two data centers for 30 seconds. What correctly describes what happens?

• A. One of the operations is rejected immediately because the system cannot proceed without consensus
• B. Both operations succeed locally on their respective replicas; when the partition heals, the system applies a conflict resolution strategy to merge the states — potentially discarding one update
• C. Both operations are buffered and held pending until the partition heals and both replicas can commit
• D. The system automatically selects the lower-latency operation as the canonical one

Answer: (B)

The defining property of eventual consistency is that writes succeed on any available replica without waiting for acknowledgment from others. During a partition, both data centers continue operating independently — this is the high-availability guarantee. When the partition heals, the system must reconcile the diverged states using a conflict resolution strategy. Last-writer-wins might discard one of the updates based on timestamps. Vector clocks would detect that both writes are concurrent. CRDTs might be able to merge both (e.g., if using a set that can represent both adds and removes). There is no automatic buffering or rejection — that would sacrifice availability, which is the whole point.

Question 2

A distributed system uses last-writer-wins (LWW) conflict resolution with wall-clock timestamps. What is the primary risk of this approach?

• A. LWW requires each node to store all historical versions of every record, creating excessive storage overhead
• B. LWW is only applicable in systems with two replicas and fails with three or more
• C. If clocks are not perfectly synchronized across nodes, the 'latest' write by timestamp may not be the causally latest write, silently discarding valid data
• D. LWW prevents the system from converging because each new write resets the convergence timer

Answer: (C)

Clock synchronization is a hard problem in distributed systems — network delays, clock drift, and hardware variation mean different nodes' clocks can disagree by milliseconds or more. A write that is causally later (a user edited a record after seeing a previous version) might have a slightly earlier timestamp than a concurrent write on another replica. LWW would then discard the causally later update — silently, with no error. Vector clocks avoid this by tracking causal ordering explicitly rather than depending on synchronized time. LWW is simple and fast, but the silent data loss is a serious risk in domains where every write is important.

Question 3

An eventually consistent system guarantees that once a network partition heals, most replicas immediately return the same value for most key.

• T. True
• F. False

Answer: False

The 'eventual' in eventual consistency is not instantaneous. The guarantee is that if writes stop and the system is allowed to propagate updates, replicas will converge. But healing a network partition does not instantly synchronize all replicas — the system must still exchange updates, detect conflicts, and apply resolution strategies, which takes time. During that window after healing, different replicas may still return different values. Applications built on eventual consistency must tolerate stale reads, not just during partitions but during the convergence period after them.

Question 4

Eventual consistency achieves high availability by allowing replicas to accept writes without waiting for acknowledgment from other replicas, at the cost of allowing temporary divergence between replicas.

• T. True
• F. False

Answer: True

This is the core tradeoff of eventual consistency as an 'AP' choice in the CAP theorem. Strong consistency requires coordination — a write must be acknowledged by a quorum before it is committed, and reads that cannot reach a quorum must be rejected or stale-blocked. This coordination fails or becomes expensive during network partitions. Eventual consistency eliminates the coordination requirement: each replica accepts writes immediately and propagates them asynchronously. The cost is temporary divergence — different replicas may return different values for the same key — which the application must be designed to tolerate.

Question 5

Why must eventually consistent systems implement a conflict resolution strategy, and what are the key tradeoffs between last-writer-wins and vector clocks?

Model answer: Eventual consistency allows independent writes on different replicas during partitions, creating the possibility of concurrent conflicting writes to the same key. When the partition heals, the system cannot simply keep both — it must reconcile them into a single state. Last-writer-wins (LWW) uses timestamps to pick the most recent write: it's simple and requires no extra metadata, but it silently discards the 'older' write and depends on clock synchronization. If clocks disagree, causally later writes can be discarded. Vector clocks track causal history per-key, detecting which writes are causally ordered (one happened before the other) and which are truly concurrent (neither caused the other). Concurrent writes are surfaced as genuine conflicts for the application or user to resolve. Vector clocks preserve data but add metadata overhead and application-level complexity.

CRDTs (conflict-free replicated data types) represent a third approach: data structures designed so that all possible merge orders produce identical results, eliminating conflicts by construction. They work for sets, counters, and some other structures but cannot be generalized to arbitrary data. The tradeoff space is fundamentally: simplicity (LWW) vs. data preservation (vector clocks) vs. structural constraints (CRDTs). Real systems like Amazon DynamoDB offer configurable conflict resolution and expose vector clock information to applications, recognizing that no single strategy fits all use cases.