LV2 · Toolooo Standard
Cache Stampede Simulator
Compare hot-key expiry, duplicate origin work and cache protection strategies on a seeded virtual clock.
What happens when a hot cached value expires under traffic? Compare duplicate origin work, user waiting and freshness on a virtual clock. Nothing connects to Redis or a database.
Advanced traffic, freshness and concurrency
Burst moves a share of existing traffic into 100 ms after min(TTL, 80% of the window); it does not add requests. The hot key receives the chosen share; remaining keys split the rest. With one key, all traffic uses it.
Current window: 15s · 1 key · 6,000 requests. Limits: 20,000 requests, 100 keys and 60 seconds. SWR uses a 3s stale window; Combined adds an origin concurrency cap of 10. Jitter is ±30% across multiple keys; single-hot-key mode deliberately keeps its expiry unchanged.
Model assumptions and what is not simulated
One shared cache and global single-flight per key. Fixed seeded arrivals, no retries, network errors, eviction or cache outages. Fresh and stale hits cost 1 ms. Each origin launch takes base response time × max(1, active concurrency / healthy concurrency), sampled once at launch; existing jobs are not rescheduled. Overload counts launches above the healthy threshold, not failures or unique incidents. This transparent slowdown is educational, not a calibrated queue, capacity forecast or benchmark.
Combined queues origin refreshes at the chosen cap. Coalescing shares a pending job; SWR also returns existing stale values only inside its window, then blocks. A cold cache cannot serve stale. The first completion refills a cache generation; late duplicate fetches finish but cannot overwrite it or extend TTL. TTL begins at refill. Hot-key mode expires key 1 at TTL and keeps other initial values fresh during the window; synchronized mode expires all keys together; random mode spreads initial expiry across 0–2×TTL.
Jitter varies multiple-key TTLs around the base and can change how many expirations fall inside a finite window. It does not remove same-key duplicate work. No proactive refresh is modeled. Staleness is time past expiry, not total data age; stale delivery is inappropriate for some data. Follow up with real failure recovery, timeout, freshness and distributed-lock tests.
Caching and request coalescing · Bounded stale-while-revalidate
What this tool does and why
Before you start
What
Compare hot-key expiry, duplicate origin work and cache protection strategies on a seeded virtual clock.
Why
Simultaneous misses can overload the dependency a cache protects. Sharing one refresh, serving bounded stale data and spreading different-key expirations solve different parts of that problem.
Your Result and Action update in the tool as you change its inputs.
Model note
This browser-side model explains the inputs you choose. Check an important decision against the real system, brief, or production constraints.
Next
How this tool stays honest
How it works
Simulate traffic through a cache to its origin. Compare no protection, request coalescing, bounded stale-while-revalidate, multi-key TTL jitter and combined concurrency protection. Inspect waiting latency, duplicate fetches, overload signals, expiry concentration and freshness trade-offs without connecting to Redis or a database.
Assumptions
The tool runs in your browser and models the information you provide. It does not know facts outside that model.
Limitations
Seeded educational virtual-clock model, not Redis benchmarking or infrastructure capacity prediction. Origin slowdown is explicit and sampled at launch. No failures, retries, distributed-lock failures, evictions or proactive refresh are modeled. Stale data requires domain-specific approval; jitter cannot fix one hot key by itself.
Understand Cache Stampede Simulator
What this tool helps you understand
Simulate traffic through a cache to its origin. Compare no protection, request coalescing, bounded stale-while-revalidate, multi-key TTL jitter and combined concurrency protection. Inspect waiting latency, duplicate fetches, overload signals, expiry concentration and freshness trade-offs without connecting to Redis or a database.
When to use it
Before choosing cache-expiry protection for a popular read or synchronized batch of keys.
Try a scenario
Compare Hot Product with coalescing, then Batch Expiry with TTL jitter. Inspect duplicate fetches, active concurrency and stale-response age before accepting a freshness trade-off.
How to read the result
Compare the same arrivals before and after protection. Check duplicate origin work and overload first, then waiting latency and stale-response age. Jitter spreads different-key expirations; coalescing shares same-key work. A quiet window does not prove a cache is protected.
Assumptions and limits
Seeded educational virtual-clock model, not Redis benchmarking or infrastructure capacity prediction. Origin slowdown is explicit and sampled at launch. No failures, retries, distributed-lock failures, evictions or proactive refresh are modeled. Stale data requires domain-specific approval; jitter cannot fix one hot key by itself.
Toolooo is part of Khizooology, created byKhizar Imtiaz (khizooo).