cache-invalidation
Skill1 starsChanged 2 months agoMITView on GitHub
Choose a caching strategy and keep the cache correct — cache-aside vs read/write-through, invalidation on write, negative caching done safely, stampede protection, and TTL as the backstop. Use when adding a cache in front of a datastore, when cached data is going stale or wrong, or when a review flags a cache-correctness issue.
In this repository73 other files it gives its agents.
- AGENTS.mdAGENTS.md
- bigquery-analyticsSkill
- mongo-aggregationSkill
- mongo-modelingSkill
- postgres-aggregationSkill
- postgres-indexingSkill
- redis-coordinationSkill
- redis-patternsSkill
- review-querySkill
- code-migrationSkill
- cut-releaseSkill
- data-migrationSkill
- deploy-serviceSkill
- hotfixSkill
- rollbackSkill
- design-endpointSkill
- design-eventSkill
- design-schemaSkill
- evolve-contractSkill
- scaffold-nestjs-moduleSkill
- scaffold-projectSkill
- incident-responseSkill
- investigate-bugSkill
- on-callSkill
- postmortemSkill
- audit-skillsSkill
- distill-review-styleSkill
- write-skillSkill
- debug-with-tracesSkill
- define-alertsSkill
- instrument-serviceSkill
- evaluate-dependencySkill
- grillSkill
- handoffSkill
- orientSkill
- phased-deliverySkill
- spikeSkill
- to-questionnaireSkill
- write-adrSkill
- write-prdSkill
- devops-pr-reviewSkill
- go-backend-pr-reviewSkill
- nestjs-backend-pr-reviewSkill
- python-backend-pr-reviewSkill
- react-frontend-pr-reviewSkill
- bisectSkill
- break-couplingSkill
- dead-code-sweepSkill
- deslopifySkill
- extract-moduleSkill
- rebase-cleanSkill
- resolve-merge-conflictsSkill
- split-commitSkill
- tddSkill
- wait-whatSkill
- wide-renameSkill
- bullmqSkill
- kafkaSkill
- sqs-consumerSkill
- audit-dependenciesSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Default to cache-aside with a TTL.
- Distinctive: line 43
When a hot key expires, many requests miss at once and all hit the DB:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cache invalidation
Two hard cases: making sure the cache reflects writes, and not letting a cache miss storm the source.
Strategy
| Pattern | How | When |
| Cache-aside (lazy) | app reads cache → miss → load from DB → populate cache | default; simple; first read after a write is a miss |
| Read-through | cache library loads on miss | same as aside, encapsulated |
| Write-through | write goes to cache + DB synchronously | reads always fresh; write latency + wasted cache for cold keys |
| Write-behind | write to cache, flush to DB async | fast writes, risk of loss on crash — rarely worth it |
Default to cache-aside with a TTL. Reach for write-through only on a hot key where the first-read miss matters.
Invalidation on write
- On update/delete: delete the key (let the next read repopulate) rather than updating it in place — updating races with concurrent loads.
- Invalidate every key that derives from the changed data: the entity key, any list/index keys it appears in, any computed rollups. Missing one is the bug.
- Cross-service: if service B caches data owned by service A, A must publish a change event B subscribes to, or B must use a short TTL and accept staleness.
Negative caching (tombstones)
- Cache "not found" too, with a short TTL, to stop repeated misses hammering the DB for a key that doesn't exist.
- The trap (real review bug): a bulk loader writes tombstones for keys it didn't find using a different filter than the single-item loader — so real records get a tombstone and 404. The bulk and single loaders must use the same predicate, or don't let the bulk loader write negatives.
Stampede protection
When a hot key expires, many requests miss at once and all hit the DB:
- Single-flight / lock — first miss takes a short lock, loads, populates; others wait briefly then read the fresh value.
- Stale-while-revalidate — serve the stale value past its soft TTL while one request refreshes in the background.
- Jittered TTL — so keys populated together don't all expire the same second.
- Pre-warm critical keys on deploy / on a schedule.
TTL is the backstop
Even with perfect invalidation, every key has a TTL so a missed invalidation self-heals within a bounded window.
Anti-patterns
- ❌ Updating a cached value in place instead of deleting it.
- ❌ Invalidating the entity key but not the list/rollup keys.
- ❌ Bulk loader writing tombstones with a different filter than the single loader.
- ❌ No stampede protection on a hot, expensive-to-compute key.
- ❌ No TTL "because we invalidate properly".
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.