liveBook · Manning

Eventual consistency

As explained in Think Distributed Systems

A form of eventual consistency that guarantees eventual delivery and convergence only after updates cease, without constraining intermediate reads or continuously updated behavior.

Eventual consistency is a weak consistency model that guarantees replicas eventually converge to the same state. It permits different replicas to return different, possibly older values while updates are still propagating. section 9.3 section 9.1.2

Basic eventual consistency provides two guarantees:

  • Eventual delivery: an update made to one nonfaulty replica eventually reaches every other nonfaulty replica. section 9.3.2
  • Weak convergence: after updates stop, all replicas eventually reach the same state. section 9.3.2
  • Before convergence, reads may return earlier values, and continuously updated systems receive no additional behavioral constraint under the basic model. section 9.3.2

Strong eventual consistency adds a stronger convergence rule: replicas that have received the same set of updates must be in the same state, even if updates continue elsewhere. section 9.3.2

A stale register read

A register initially contains 0. After a process writes 10, another read may still return 0 under eventual consistency. Linearizability would require the read to return the most recent value, whereas eventual consistency permits an intermittent value. section 9.1.2

Because clients may update disconnected replicas concurrently, replicas need conflict resolution. Applications can define reconciliation rules, or CRDTs can combine updates using convergence-preserving operations or merges. section 9.3.3

Table 9.4 Operation-based and state-based grow-only set

Operation-based grow-only set

State-based grow-only set

// apply adds an element to
// the set

on init do
set := { }
end

on receive (add x) do
set := set
∪ { x }
end

// merge takes the union of
// two sets

on init do
set := { }
end

on receive (set') do
set := set
∪ set'
end

Compares operation-based and state-based grow-only sets, showing how local updates or state merges can preserve convergence. section 9.3.3

How Think Distributed Systems covers it

How deep it goes
Defines basic and strong guarantees, illustrates stale reads, and sketches reconciliation without developing a complete protocol.
Examples
Uses a stale register read, the Amazon shopping cart, and operation-based or state-based grow-only sets.
What it assumes
Assumes replicas, distributed components, delayed or lost messages, and application-level validity while defining consistency interpretations.
What you can do after
Evaluate/understand when stale reads, delayed convergence, and conflict resolution are acceptable for replicated applications.
How it connects
Connects eventual consistency to linearizability, conflict resolution, CRDTs, availability, latency, and CAP tradeoffs.

Also explained in

Compare how 6 books explain eventual consistency →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Distributed Systems. The section links point to the parts of the book it draws on.