Cache invalidation
Skill Amey-Thakur/AI-SKILLS/skills/performance/cache-invalidation
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill cache-invalidationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Keep cached data correct as the source changes using write-through, event-driven eviction, and versioned keys. Use when a cache exists and stale reads are a risk, or when users report seeing old data after a write.
SKILL.md
2.7 KB, as published. Nobody here has run it
Cache invalidation
The hard part of caching is not filling the cache, it is knowing the moment a cached value became a lie. A stale read is a correctness bug wearing good latency. Every cache needs a written answer to one question: when the source changes, how does the copy learn?
Method
- Enumerate every write path to the source of truth. The API handler, the admin tool, the batch job, the replication stream, the manual database fix. Any path that mutates data and does not touch the cache is a stale-read generator. List them before choosing a mechanism.
- Prefer write-through or write-behind for data you own. Update the cache in the same transaction or commit hook that updates the store, so the two move together. Write-through updates synchronously; write-behind queues the update. Either beats hoping a TTL expires before someone reads.
- Use events for cross-service invalidation. When another service owns the write, subscribe to its change stream (Kafka, a Postgres logical replication feed, an outbox table) and evict on the event. Do not poll, and do not assume a short TTL papers over another team's write.
- Version keys instead of hunting them down. For values derived from a
schema or ruleset, embed a version in the key (
product:42:v7). Bump the version and every consumer misses to fresh data at once, with no scan and no delete storm. Old keys age out on their own TTL. - Invalidate the exact set, and its dependents. Editing a product must
drop
product:42and any aggregate that includes it: the category listing, the search facet, the homepage block. Map these dependencies explicitly; the bug is always the derived key you forgot. - Make eviction idempotent and failure-tolerant. A delete that runs twice must be harmless, and a missed event must be recoverable by a bounded TTL as backstop. Never rely on the invalidation firing exactly once.
Litmus tests
- Name a write path where the cache is not updated: if one exists, it leaks.
- After an edit, does every derived and aggregate key reflect it, not just the primary key?
- If an invalidation event is dropped, does a TTL still bound the staleness?
Boundaries
This assumes the cache layout and TTLs are already chosen; that design belongs to caching-strategy. Refresh scheduling for precomputed aggregates is handled in materialized-views. Distributed multi-region coherence adds consensus concerns beyond a single cache tier.