Coalescing misses without stale leaders
Bound duplicate origin work while preserving waiter deadlines and rejecting outdated refresh results.
On this page
The question for today
What you’ll understand
- Explain the scope and limits of per-key duplicate suppression.
- Separate a refresh lease from a storage-enforced publication fence.
- Budget waiters, deadlines, and origin capacity during failures.
A hot key expires and hundreds of callers discover the miss together. Without coordination, each can launch the same expensive origin read, making the cache failure more costly precisely when load is high. Coalescing selects one in-progress computation for a key and shares its result with compatible waiters. That saves duplicate work, but introduces its own lifecycle: who leads, who waits, what happens on timeout, and whether an old leader can publish after ownership changes.
One key, one in-progress computation in a defined scope
A process-local single-flight group suppresses duplicate work within that group, not across all processes or regions. Its key must preserve the same tenant and authorization boundaries as the cached result. Joining unrelated requests because their URL looks similar can repeat a cache-key leak before anything is stored. A follower's cancellation also need not imply that every other waiter should lose the shared computation; choose separate waiter and producer lifetime rules deliberately.
Waiters consume memory, connections, and deadline budget. A slow leader can collect a large crowd even when origin QPS falls. Bound waiting and offer a documented outcome such as a permitted stale response, a retryable error, or independent fallback only when capacity permits. If every timed-out follower immediately starts a new origin operation, duplicate suppression can collapse into periodic waves. Measure concurrent producers and waiters, not merely the number of successful cache fills.
A lease does not stop a delayed writer by itself
A distributed lease can let one refresher proceed temporarily, but the process may pause beyond its lease and later resume. A new leader might already have fetched and published a newer value. Expiry of the old lease does not prevent that old process from issuing a write. Publication needs a condition checked atomically at the storage boundary, such as a current generation token and source-version guard. Releasing a lease must also verify ownership rather than deleting a successor's lock.
Distinguish fencing the refresh generation from proving data freshness. A newer lease holder can still read a lagging origin replica, so a larger lease token does not necessarily mean a newer source value. If freshness requires source ordering, carry a trustworthy source version or validate against authoritative state. On cache eviction or restart, preserve or reconstruct the guard needed to reject stale publication; forgetting the guard can allow a delayed result to become current again.
Recovery must preserve origin capacity
Decide how a failed refresh ends the shared call and how retries are scheduled. Jitter and backoff reduce synchronized retries but do not create origin capacity. Cache a permitted failure outcome only under an explicit short negative policy; do not accidentally turn a transient permission or transport error into authoritative nonexistence. Exercise leader crash, delayed success, lease takeover, canceled followers, and a cache reconnect with a cold key. Verify both returned values and origin work during those transitions.
The queue lab models only aggregate work pressure. Reset and set both λ=4, μ=2, predict backlog growth from four and Step. Reset and re-set λ=2, μ=3, predict decline, then Step. It has no keys, leases, leaders, or waiters, so it cannot demonstrate single-flight correctness. Interpret reduced arrivals as a hypothetical result of successful coalescing, then state how real producer and waiter metrics would verify that reduction without assuming duplicates vanished across process boundaries.
Work it through
A hot miss and a delayed leader
A key receives 500 requests/s while a fetch takes 0.2 seconds. Assume steady arrivals, all requests are compatible, and one coalescing group covers them. Later, leader generation 7 pauses and generation 8 takes over.
About 500×0.2=100 requests arrive during the uncached interval. Without suppression they can initiate roughly 100 duplicate origin fetches under this simple timing model.
A successful single-flight group can use one producer for that interval and share its result with the other compatible callers, but those callers still require bounded waiting and may have different deadlines.
After takeover, storage must reject generation 7's delayed publication when current generation is 8. A lease timer alone cannot enforce that rejection. If source versions also matter, generation 8 must meet the authoritative version floor rather than relying only on its newer lease number.
Coalescing reduces duplicate work only within its scope and lifecycle. Safe takeover requires an enforced publication condition.
The living notebook
Explore the model
Interactive lab · queue
Reduced producers need measured evidence
Reset, set λ=4, μ=2, predict growth, then Step. Reset and re-set λ=2, μ=3, predict decline, then Step. This fluid aggregate model has no per-key coalescing, leases, publication guards, or waiter deadlines.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forFewer producers can relieve origin pressure, but correctness and scope require explicit per-key coordination.
Pause & reason
Check your understanding
Your turn
Try it yourself
A process-local single-flight group is deployed in twelve independent workers. Each worker receives a simultaneous miss for the same key and has no shared coordinator. What is the possible producer count, and why does one-per-process not imply one cluster-wide?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Count independent coordination scopes rather than cached keys.
Compare with the solution
Up to twelve producers can run, one in each independent group. Local duplicate suppression has no knowledge of the other eleven workers. A distributed scheme could reduce that count but would add takeover, publication, and failure semantics. The origin must tolerate the actual scope or admission must limit concurrent work; a local hit metric alone cannot prove a global one-producer invariant.
Keep the idea
Take it with you
- Duplicate suppression has a key-equivalence contract and a finite coordination scope.
- Lease expiry is not storage-enforced fencing.
- Bound waiter and retry behavior as carefully as producer count.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.