TL;DR
A new InfoQ article by Gabor Koos (Jan 28, 2026) makes a bold claim: cache stampede — the dreaded thundering herd on a cache miss — has a one-page fix on Cloudflare Durable Objects. Treat the in-flight computation and the finished response as two states of the same cache entry, owned by a per-key singleton. No Redis. No distributed locks. No marker rows. No polling loops. Just one Promise everyone awaits.
What's new
The pattern itself is not new — Akka and Microsoft Orleans actor systems have done this for years. What's new is the framing for the serverless edge crowd: Durable Objects (DOs) give you Akka-grade actor semantics on Cloudflare's global network, which means you can finally write the textbook fix for thundering herds inside a Worker — in about 8 lines of JavaScript.
The InfoQ piece names the abstraction explicitly: cached and inflight are not separate problems handled by separate systems. They are two states of the same object.
Why it matters
Anyone who has run a popular API at scale has lived this story: a hot URL falls out of cache, 1,000 requests hit the origin in the same second, the database melts, latency spikes, an incident channel lights up. The classic mitigations all add complexity:
- Redis with SETNX-based locks — needs a coordination service, lease renewal, lock TTLs.
- Singleflight in your app process — works on one box, fails the moment your load balancer fans out.
- Eventually-consistent KV with "in-progress" markers — needs polling, races on the marker itself.
Durable Objects collapse all of that into one primitive: per-key singleton routing. Every request for the same key lands on the same logical instance, anywhere on Earth, and that instance handles them serially with shared in-memory state. The lock disappears because there is no concurrency to coordinate.
Technical facts
The InfoQ pattern relies on three Durable Object guarantees:
| Guarantee | What it gives you |
|---|---|
| Per-key singleton routing | All requests for an object id route to the same instance, regardless of geographic origin. |
| Shared in-memory state | Unlike stateless Workers, DOs retain in-memory state between requests — you can park a Promise on this. |
| Serialized execution | Requests to one DO are processed sequentially. No explicit lock needed. |
The minimal pattern is almost insultingly small:
if (!this.inflight) {
this.inflight = this.compute().then((response) => {
this.cached = response.clone();
this.inflight = undefined;
return response;
});
}
return (await this.inflight).clone();That is the whole idea. One promise. Everyone awaits the same one. First miss does the work; the next 999 callers get the same result without re-triggering it. When the promise resolves, it transitions into cached, and subsequent requests skip computation entirely.
It is worth noting how DO storage itself behaves: get() returns immediately for in-cache keys without a context switch, and put() completes instantaneously by writing to cache first — so the persistence layer that backs cached doesn't drag the pattern down.
Comparison
| Approach | Cross-node dedup? | Coordination layer | Implements pattern cleanly? |
|---|---|---|---|
| In-process Promise singleflight | No | None | Partial — fails across nodes |
| Redis + distributed locks | Yes | Lock service, leases, TTLs | Yes, but heavy |
| Eventually-consistent KV + markers | Weak | Marker rows + polling | No — "cannot represent execution or allow multiple callers to await the same in-memory operation without polling" |
| Durable Objects / Akka / Orleans | Yes via routing | None — singleton is the coordination | Yes |
The advantage over Redis is structural, not just ergonomic: you remove an entire category of distributed-systems problem (lock leases, lease renewal, lease handoff, lease expiry under partition) by removing the lock.
Use cases
The pattern shines when duplicate work is expensive and concurrency is spikey:
- Edge APIs serving long-tail content where any given URL is rarely hit — until it is, and then it gets hit hard.
- Aggregation endpoints that fan out to several upstream services and combine them into one response.
- Expensive upstream integrations — rate-limited third-party APIs, paid LLM inference calls, slow analytical queries.
Real-world DO scaling proof exists. Cloudflare rebuilt their own Queues product on top of Durable Objects and reported send latency dropping from ~200ms to ~60ms (a 70% cut) and per-queue throughput jumping from 400 to 5,000 messages per second — a 12.5× increase. The primitive holds up under load.
Limitations & pricing
- Hot key bottleneck. Routing every request for one key through one owner introduces a serialization point. An extremely popular key can hit single-DO throughput limits — the very thing that makes the pattern correct also limits its ceiling.
- Runtime dependency. Stateless Lambda + DynamoDB cannot replicate this cleanly. You need an actor-style runtime — DOs, Akka, Orleans, or equivalent.
- State resets on hibernation. DOs hibernate after idle, wiping in-memory state. Completed results that need to survive must be written to durable storage (DO storage, KV, R2).
- Production complexity. The 8-line example silently ignores timeouts, retries, eviction policy, error propagation, and memory limits. Real implementations are bigger.
- Not a full cache replacement. The pattern handles the miss-and-stampede window. Long-term caching should still happen in a real cache tier.
- Author's own caveat: "Primarily a design proposal, not a battle-tested recipe." Production case studies of this exact pattern are still scarce.
What's next
The interesting question is not whether this works — the primitives are well-understood and Akka/Orleans shops have shipped this pattern for a decade. The interesting question is whether the serverless-edge crowd will adopt it. Most teams reach for Redis reflexively the moment the word "cache" appears, partly because that is what the tutorials say and partly because Redis is what runs in their existing stack.
If Durable Objects keep delivering the kind of numbers Cloudflare Queues showed, expect a shift: cache-stampede protection moves from a separate distributed-systems problem solved by Redis to a property you get for free by structuring your edge worker as a per-key actor. That is a meaningful simplification.
Nguồn: InfoQ — One Cache to Rule Them All, Cloudflare Durable Objects docs, Cloudflare Queues 10× speedup.