Replication & Quorums

1 / 30

The beginner lie

“Replication means copies.”

The hard part is not making copies. The hard part is deciding which copies matter when they disagree.

2 / 30

The core model

  • N: number of replicas for a key
  • R: responses required for read success
  • W: acknowledgments required for write success

A quorum is a success threshold over a replica set.

3 / 30

One key, three replicas

A = old
B = old
C = old

Write new reaches A and B.

A = new
B = new
C = old

A read from C alone is stale.

4 / 30

Sets, not slogans

Write acknowledgments: {A, B}
Read responses:        {B, C}
Intersection:          {B}

The overlap is where the read can discover the write.

5 / 30

Read/write intersection

R + W > N

If the sum is bigger than the universe, disjoint sets are impossible.

6 / 30

Counterexample

N=3, R=1, W=1

Write succeeds on {A}
Read succeeds on {C}

No overlap. The read can miss the write.

7 / 30

Write/write intersection

W + W > N

If two write quorums can be disjoint, two writes can both succeed without any replica seeing both.

8 / 30

Availability cost

Read survives  N - R  replica failures
Write survives N - W  replica failures

Increasing consistency thresholds usually reduces availability.

9 / 30

Quorum profiles

N=3, R=2, W=2

  • Read/write intersects
  • Write/write intersects
  • Reads tolerate one failure
  • Writes tolerate one failure

Balanced, not free.

10 / 30

Fast reads profile

N=3, R=1, W=3

  • Reads are fast
  • Writes require all replicas
  • Good latest-read property after successful full writes
  • Poor write availability
11 / 30

Fast writes profile

N=3, R=3, W=1

  • Writes are fast
  • Reads require all replicas
  • Write/write conflicts possible
  • Write availability is high, read availability is low
12 / 30

Read path

  1. Find responsible replicas
  2. Send read requests
  3. Wait for R live responses
  4. Pick newest version
  5. Return value
  6. Repair stale replicas
13 / 30

Read repair

A -> value=a, ts=1
B -> value=b, ts=3
C -> value=a, ts=2

Return b. Repair A and C.

14 / 30

Hinted handoff

Responsible replicas: {A, B, C}

B is down.

Write to D with a hint:

D stores value, hintFor=B

Later D replays to B.

15 / 30

Hinted handoff nuance

Hinted handoff improves availability. It does not erase the distinction between responsible replicas and temporary holders.

16 / 30

Strict vs sloppy quorum

Strict quorum:

write only to responsible replicas

Sloppy quorum:

write to fallback nodes if responsible replicas are down

Different consistency implications.

17 / 30

Replica placement

A quorum applies to a concrete replica set.

Before asking “does R intersect W?” ask:

Which nodes are responsible for this key?
18 / 30

Hash ring

0 ---- A ---- B ---- C ---- D ---- max

Key hash chooses the next token. Additional replicas are the next unique nodes around the ring.

19 / 30

Virtual nodes

One physical node may own multiple tokens.

Replica selection must avoid returning the same physical node twice.

20 / 30

Timestamp problem

“Highest timestamp wins” is simple.

It can also lose data when writes are concurrent or clocks drift.

21 / 30

Version vectors

X = {A:2, B:1}
Y = {A:1, B:1}

X dominates Y.

X = {A:1}
Y = {B:1}

Concurrent conflict.

22 / 30

Frontier

The non-dominated versions are the frontier.

One frontier value: no conflict. Multiple different frontier values: conflict.

23 / 30

Anti-entropy

Read repair heals hot keys. Anti-entropy heals cold keys.

Compare summaries, find divergence, copy newer versions.

24 / 30

Session guarantees

Read-your-writes:

After writing v5, do not read v4.

Monotonic reads:

After reading v5, do not later read v4.
25 / 30

Latency effect

Responses:

[8ms, 12ms, 40ms, 120ms, timeout]

R=1 returns after 8ms. R=3 returns after 40ms. R=5 fails or waits for timeout.

26 / 30

What formulas do not cover

  • Sloppy quorum behavior
  • Clock skew
  • Concurrent writes
  • Session routing
  • Cold-key repair
  • Tail latency
  • Operational limits on hints
27 / 30

Problem sequence

  1. Quorum intersection
  2. Availability analysis
  3. Read repair
  4. Quorum read plan
  5. Hinted handoff
  6. Replica placement
  7. Latency planner
  8. Version vectors
  9. Anti-entropy
  10. Session guarantees
28 / 30

Capstone

Build a small Dynamo-style key-value simulator.

Must support:

  • replica placement
  • quorum reads/writes
  • hinted handoff
  • read repair
  • anti-entropy
  • session checks
29 / 30

Final standard

A learner should be able to explain stale reads, conflict creation, and repair behavior from an actual event timeline.

30 / 30
Use arrow keys or click edges to navigate. Press H to toggle help, F for fullscreen.