Skip to content

PATTERN Cited by 1 source

Early ack on durability

Intent

Respond to the client as soon as a write has reached the durable stage of the two-phase tentative-then-complete commit path, without waiting for the subsequent complete messages to propagate to followers. Saves one client-visible round-trip at the cost of complicating read-path consistency.

Shape

Late-ack (conservative, baseline):

Leader → Followers: tentative(X)
Followers → Leader: ack
Leader → Followers: complete(X)
Followers: apply X
Leader → Client: ack          ← two round-trips

Early-ack (this pattern):

Leader → Followers: tentative(X)
Followers → Leader: ack
Leader → Client: ack          ← one round-trip
Leader → Followers: complete(X)   (asynchronous)
Followers: apply X

Canonical formulation

Sugu Sougoumarane, consensus-algorithms-at-scale part 6: "A leader could respond to the client with a success message as soon as it has become durable. However, it has the option of delaying the acknowledgement until it has also sent the completion message to the followers. Waiting until completion costs two round-trips and is therefore slower than an early response. On the other hand, it improves the performance of quorum reads."

(Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-6-completing-requests)

The read-consistency cost

Early-ack trades commit latency for a more expensive read path. After the client ack, a subsequent read needs to see the durable-but-not-yet-applied write to preserve read-your-writes consistency. Two mechanisms solve this:

Option A: quorum reads

The reader contacts a durability-quorum of followers to find the latest durable value, including tentative records not yet materialised. Works in any election shape but costs a read-time broadcast per read.

Option B: leader lease

Under lock-based leader election, the leader holds a valid lease; no other leader exists; leader-local reads are authoritative. The reader hits the leader, and the leader knows about the durable request (it's the one that declared durability), so the read is trivially consistent — no broadcast needed.

Sugu's argument: "For systems that use lock-based failovers, reads can be sent to the current leader instead of performing quorum reads. This allows for the leader to respond as soon as it has received the necessary acknowledgements." The lease + early-ack combination gives both cheap writes and cheap reads.

Trade-off summary

Write path Read path Best fit
Late-ack Quorum or lease Commit latency not critical; reads are frequent
Early-ack + quorum reads Quorum Lock-free election (no stable leader / lease)
Early-ack + lease reads Leader-local Lock-based election with stable leader

The bottom row is Sugu's recommendation for large-scale consensus systems: pair the lock-based-election family with early-ack on the commit path, and reap both latency wins simultaneously.

Failure-mode considerations

Early-ack is safe because durability guarantees the write survives: even if the leader crashes before sending complete, the next elector will find tentative records on a quorum of followers and propagate them to completion under the new leader. The client saw "ack" and the cluster will eventually materialise the effect — the mutual-exclusion invariant of two-phase completion rules out the alternative.

What early-ack does not protect against: reads that race with the asynchronous complete round-trip. A read that hits a follower before it has received complete will miss the write. This is why a quorum read or a lease is required — pick one.

When to prefer late-ack

  • Eventually-consistent reads are acceptable → late-ack plus follower-local reads gets you throughput at the cost of some staleness.
  • Quorum reads are prohibitively expensive and you do not have a leader lease → late-ack turns each read into a local lookup on an already-materialised value, amortising the commit cost across the reads.

Seen in

Last updated · 347 distilled / 1,201 read