Questions: Strong Eventual Consistency

Question 1

Two replicas both receive updates A and B. Replica 1 receives A then B; Replica 2 receives B then A. Under plain eventual consistency (but not SEC), what is guaranteed?

• A. Both replicas will converge to the same state, because they received the same updates
• B. The replicas may converge to different states depending on how order-dependent the operations are
• C. Replica 1's state is authoritative because it received A first
• D. The system will detect the conflict and roll back one of the updates

Answer: (B)

Plain eventual consistency only guarantees that replicas *eventually* converge if updates stop arriving — it says nothing about *whether* two replicas with the same update set will produce identical states. If operations are order-dependent (e.g., 'insert at position 5'), different delivery orders can produce different results. SEC adds the determinism guarantee: same update set → same final state, regardless of order. This is the exact gap that CRDTs are designed to fill.

Question 2

What property of CRDTs mathematically guarantees that replicas satisfying SEC will converge to the same state?

• A. Operations are commutative (order-independent), associative (grouping-independent), and idempotent (duplicates have no effect)
• B. CRDTs use a central coordinator to serialize all updates before applying them
• C. CRDTs timestamp every operation and use last-write-wins conflict resolution
• D. CRDTs prevent concurrent writes from being accepted during network partitions

Answer: (A)

These three algebraic properties together guarantee that the final merged state depends only on *which* updates were received, not the order, grouping, or how many times they arrived. A grow-only counter is the clearest example: incrementing by 1 then by 2 gives the same result as incrementing by 2 then by 1 (commutative), and incrementing twice by the same operation gives the same result as once (idempotent). These properties make convergence a mathematical certainty rather than an operational hope. Options B and D contradict the high-availability premise of SEC; option C describes one CRDT type (LWW register) but not the general mathematical foundation.

Question 3

Under strong eventual consistency, two replicas that have received the same set of updates will converge to identical states even if those updates arrived in different orders.

• T. True
• F. False

Answer: True

This is the defining property of SEC, which distinguishes it from plain eventual consistency. 'Same updates in, same state out' — regardless of delivery order. This is not a liveness guarantee (it doesn't say when convergence happens) but a safety guarantee about the convergence value. The property is achieved through CRDT operations that are commutative and idempotent by construction, making the final state a function of the update *set* alone, not the update *sequence*.

Question 4

To maintain strong eventual consistency, replicas should refuse concurrent writes during a network partition and wait for the partition to heal before accepting new updates.

• T. True
• F. False

Answer: False

This confuses SEC with strong consistency (CP systems in CAP terms). SEC is explicitly designed for AP systems: every replica accepts writes during a partition, maintaining high availability. The CRDT properties (commutativity, idempotence) ensure that when the partition heals and updates propagate, all replicas automatically converge — without requiring any coordination, consensus, or write rejection during the partition. Refusing writes during partitions is the approach of systems like Zookeeper or Paxos-based databases, not CRDT-based SEC systems.

Question 5

Explain why plain eventual consistency is insufficient for collaborative text editing, and how strong eventual consistency addresses the gap.

Model answer: In collaborative editing, two users may insert text at the same position simultaneously, and their edits reach different replicas in different orders. Plain eventual consistency only guarantees that replicas will eventually converge — but doesn't guarantee they'll converge to the *same* text. Different orderings of the same inserts can produce different final documents. SEC requires that any two replicas receiving the same set of edits must produce identical text, regardless of order. CRDT-based text structures (like RGA or LSEQ) achieve this by assigning each character a globally unique identifier, making the merge rule deterministic and order-independent.

This is precisely why Google Docs, Figma, and similar tools use CRDT or OT (operational transformation) approaches. The alternative — locking documents or serializing edits through a central server — sacrifices availability and introduces latency. SEC-based CRDTs allow every user to edit simultaneously and locally (low latency, high availability) while guaranteeing automatic, deterministic reconciliation.