# If I build edge caching with Cloudflare Workers + KV, how do I do invalidation?

> The moment a price changes, write through to KV or purge the key in the same transaction or outbox; a short TTL and versioned keys are only the safety net.

- Asked: 2026-05-08
- Answered: 2026-05-11
- Asked by: Tolga
- Tags: altyapi, cloudflare, caching
- Source: https://muhammetsafak.com/just-ask/edge-caching-with-cloudflare-workers-kv-and-invalidation/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** Some endpoints of my API (e.g. dynamic price lists) don't change often but must return very fast from the location nearest the user. Instead of sending all traffic to origin (EC2), I want to handle requests at the edge with Cloudflare Workers and cache them in KV.

How should I set up cache invalidation so that when a price changes at origin, the edge updates instantly?


Short answer: don't rely on TTL alone — TTL is eventual and serves the **stale price** until it expires. Make invalidation push-based and event-driven.

## Short answer

In your scenario the unacceptable thing is the "wrong price" window. The fix is to push the change to the edge, not leave it waiting. This is a classic [backend architecture](/expertise/backend/) decision: treat the cache as a speed layer and keep the source of truth at origin.

## Why

1. **TTL is a staleness bound, not an invalidation mechanism.** Until it expires the edge keeps serving the old value; for money-affecting data that window is unacceptable.

2. **KV is a cache, not the source.** Your source of truth is the origin DB; KV is a fast copy of it. This mindset lets you re-seed from origin whenever KV gets corrupted or inconsistent.

3. **KV is globally eventually consistent.** Writes can take up to 60 seconds or more to propagate worldwide; a small inconsistency window is unavoidable. If you need instant global correctness, KV is the wrong layer.

## What to do

1. **Write-through (or purge) on change.** The moment a price changes at origin, call Cloudflare's API in the same transaction/outbox and write the new value into KV, or delete the key. That makes the update part of the write itself, not a separate "hope it runs" step.

2. **Key by entity+version.** Stamp each value with a version (like `price:42:v7`). If the Worker sees an old version it can **serve-stale-while-revalidate** and refresh in the background.

3. **Keep a short TTL as a safety net.** If a push invalidation misses for some reason, a short TTL caps staleness to a few seconds at worst. Let TTL be the last line of defense, not the only one.

**Bottom line:** I'd set up the trio of **write-through (or purge) on change + a short TTL safety net + versioned keys.** A TTL-only solution is wrong for money-affecting data like prices; with push-based invalidation, the edge updates the instant origin changes. Design knowing KV's seconds-long propagation window — use it as a fast, refreshable cache, not as the source of truth.

## Related Reading

- [Should I put my API server behind a Cloudflare Tunnel and close port 443 to the internet?](https://muhammetsafak.com/just-ask/should-i-put-my-api-behind-a-cloudflare-tunnel/) — Just Ask
- [Why is keeping the key in .env risky when encrypting sensitive financial data — what do KMS/Vault give you?](https://muhammetsafak.com/just-ask/encrypting-sensitive-financial-data-at-rest-and-key-management/) — Just Ask
- [How do I set up secretless AWS access in CI/CD with OIDC and IAM roles?](https://muhammetsafak.com/just-ask/secretless-ci-cd-with-aws-iam-roles-and-oidc/) — Just Ask