Systems / 2026 / Live in the browser
Cache Stampede Lab
XFetch early expiration, single-flight, memcache leases and stale-while-revalidate, compared on one seeded simulation of a hot cache key expiring in front of a database.
01
The problem
When a hot key expires, every request that arrives before the rebuild finishes asks the database for the same answer. At 2,000 reads a second and a 200ms query, one expiry becomes hundreds of identical queries, the database queues them, and readers wait seconds for a value that was cached a moment ago.
02
How I approached it
A discrete-event simulation sends Poisson reads to 8 app servers sharing one cache, with the database modelled as 16 query slots and a FIFO queue. Five policies run on the same seed: a plain TTL, per-server single-flight, a cluster-wide lease as in Facebook's memcache paper, XFetch from Vattani et al. (VLDB 2015), and RFC 5861 stale-while-revalidate. The XFetch rule is tested against its closed form exp(-x / (delta * beta)) over 50,000 draws. createCache packages single-flight, XFetch with the loader's measured duration as delta, and a stale window behind one get() call, with an injectable clock for tests.
03
The outcome
Over five seeds a plain TTL makes 2,006 database rebuilds in a minute with a 386-query backlog and a 1.7s p99. A lease cuts that to 11 rebuilds but readers still wait about 147ms at p99. XFetch needs 41 rebuilds and no reader ever waits, with no coordination between servers. Zero dependencies, 22 tests.
Related work
Five rate limiting algorithms replaying the same traffic side by side, plus a node:http middleware that advertises quota with the IETF RateLimit headers.
Jittered backoff, an SRE retry budget and a circuit breaker, with seeded simulations of a contended database row and of a retry storm that outlives the outage that started it.
A last-writer-wins CRDT with vector clocks and causal delivery, written from scratch, so three replicas can go offline, edit the same keys and reconverge without a server deciding anything.