Design a caching strategy with safe invalidation
Decides what to cache, where, and for how long, with invalidation rules and failure modes so the cache doesn't serve wrong data.
The prompt
Help me design caching for a slow or expensive part of my system.
What's slow or expensive: [ENDPOINT, QUERY, OR COMPUTATION, WITH CURRENT LATENCY OR COST IF KNOWN]
Read vs. write pattern: [HOW OFTEN DATA IS READ AND CHANGED]
How stale can data be? [e.g. "must be exact", "a few minutes is fine", "varies by field"]
Is data per-user or shared? [DETAILS, INCLUDING ANY PERMISSIONS OR PRIVATE DATA]
Stack and available tools: [e.g. "Redis", "CDN", "in-process memory", "HTTP caching"]
Scale: [REQUESTS PER SECOND, NUMBER OF INSTANCES]
Design:
1. Where to cache: browser/HTTP headers, CDN, application memory, distributed cache, database materialized views. Recommend one or a combination, with reasons.
2. Pattern: cache-aside, read-through, write-through, or write-behind, and why.
3. Keys: a key scheme including versioning and tenant/user scope. Explicitly check that one user can never see another user's cached data.
4. Expiry and invalidation: TTLs per data type and event-based invalidation on writes. Point out where invalidation could be missed.
5. Failure modes: cache stampede, hot keys, cold start after a deploy or flush, stale data after failed invalidation, cache outage. Give a mitigation for each.
6. Measurement: hit rate, latency, and staleness metrics to confirm it's working.
Return: the design summary, a table (data, cache layer, key, TTL, invalidation trigger), example code for my stack, and a list of "don't cache this" items.
Highlighted [brackets] are blanks to replace with your own details.
Fill in the blanks and use this promptMore Software Development prompts
What to fill in
- HOW OFTEN DATA IS READ AND CHANGED
- DETAILS, INCLUDING ANY PERMISSIONS OR PRIVATE DATA
- e.g. "Redis", "CDN", "in-process memory", "HTTP caching"
- REQUESTS PER SECOND, NUMBER OF INSTANCES
How this prompt is built
This prompt follows the Few-Shot structure (Few-shot prompting). A few-shot prompt includes one or more worked examples of the input and the output you want, so the model can copy the pattern instead of guessing it.
Related prompts
- Plan a zero-downtime database migrationCreates a step-by-step expand-and-contract plan for a schema or data change, with backfill, verification, and rollback at each step.
- Refactor code to be cleaner and easier to maintainImproves structure, naming, and design without changing behavior.
- Design a database schemaEntities, relationships, keys, indexes, and migrations for your data model.
- Write a farm business plan for a loan or grant applicationA lender-ready farm business plan with production, market, and financial sections, flagging every figure you still need to supply.