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. Two of these are security findings rather than performance ones — a key that collides across tenants, and a cache that survives a deploy the schema did not — and they are marked as such rather than filed 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 practising. Safe-to-retry-only gives the cases a retry policy handles; work-already-happened gives the cases it does not, which are the ones that cost money.
- Seed
- Any word makes the draw reproducible, 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. Nothing you enter or copy is transmitted or stored between visits.
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.