Cache Scenario Generator
A cache turns a correctness problem into a performance one, and occasionally back again. The failures are rarely that the cache is empty; they are that it holds the wrong thing confidently. The write that succeeds while the next read still returns the old value. The popular key that expires and sends a thousand simultaneous rebuilds at the database. The 404 that is cached and outlives the thing it said was missing. The key built from a resource id that is only unique within a tenant.
What this generator does
Produces the situations in which a cache returns a wrong answer, each with the behaviour that would be correct. One of these is a security finding rather than a performance one — a key that collides across tenants — and its expected behaviour says so rather than filing it alongside the tuning advice.
How to use this tool
- Choose how many scenarios you want.
- Filter to the ones where the underlying write already happened, if that is what you are reviewing.
- Draw, then copy them into your test plan.
- Seed it to reproduce the same set.
Understanding the controls
- How many scenarios
- Six distinct cache scenarios. It will not pad the list by repeating them.
- Narrow it down
- Two filters that change what you are reviewing. Safe-to-retry-only keeps two of the six, the stale read and the herd on expiry; work-already-happened keeps the two where a write went through — the stale read and the failed invalidation.
- Seed
- Any word makes the draw reproducible while the generator is unchanged, so a test plan can be re-derived from the same seed months later. Leave it empty for a different set each time.
Common use cases
- Testing read-after-write behaviour, which unit tests almost never exercise together
- Reviewing whether cache keys are namespaced per tenant before it becomes a data-leak incident
- Planning for the moment a hot key expires under load
- Deciding a deliberate staleness budget instead of an accidental one
- Checking that a deploy with a changed object shape misses rather than misreads
How this generator works
A hand-written catalogue, shuffled without replacement, checked for coherence before display. The check verifies that a scenario placed after a side effect actually claims one, so advice about reconciling cannot be attached to a case where nothing was written.
Randomness and fairness
Which scenarios you get is random. Without a seed the draw uses the browser's cryptographically secure generator; with a seed a small deterministic generator, which is reproducible and therefore explicitly not cryptographically secure.
For how randomness is produced across the whole site, see how Generate Random works.
Assumptions this tool makes
- An application-level cache sits between the client and a source of truth.
- Cache entries may outlive a deployment.
Limitations and good to know
- It covers application-level caching. CDN and browser cache behaviour overlap but have their own rules and headers.
- No cache implementation is assumed. Some of these are impossible in some systems and unavoidable in others.
- It gives scenarios, not benchmarks. Whether your hit rate is good is a different question.
Common mistakes
- One TTL for everything
- The right lifetime for a found value and a not-found value are rarely the same, and a cached negative can outlive the thing that was missing.
- Testing writes and reads separately
- Read-after-write staleness only appears in the sequence. Two green tests can hide it completely.
- Building keys from a resource id alone
- Unique within a tenant is not unique. This is the scenario that turns a cache into a data-leak incident.
Practical tips
- Version the cache key alongside the object shape, so a deploy misses instead of misreading old data.
- Add jitter to TTLs of keys populated together, or they will expire together too.
- Measure invalidation failures. Fire-and-forget invalidation fails silently by design.
Privacy and your data
Everything is generated in your browser. The seed you enter and whatever you copy are not transmitted or stored between visits. The number of scenarios that came back is counted, with the fact that the tool ran.
Frequently asked questions
- Is a cached 404 really a problem?
- Frequently. If the resource appears a second later and the negative entry has a long lifetime, the system insists it does not exist for as long as the TTL lasts.
- How is this different from just reading about caching?
- It gives you cases to test rather than principles to agree with. Each scenario names the specific trap and the behaviour you should be able to prove.
- Which of these is the most serious?
- The cross-tenant key collision, because it is a data-disclosure bug wearing a performance costume.
Related generators
- API Failure Scenario GeneratorNine distinct ways an API call fails, each saying where in the request it broke, whether a retry is safe, and what the client should do.
- Rate Limit Scenario GeneratorThe ways rate limiting actually bites — missing Retry-After, per-key budgets, silent throttling — with the expected client behaviour for each.
- Synthetic Test Data GeneratorBuild a whole table of fictional records from the fields you choose, then export them as a table, JSON, CSV or SQL inserts.
- Idempotency Scenario GeneratorThe cases an idempotency key has to survive — same key with a different body, two retries in flight at once, keys that expire before the client gives up.