# 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://www.muhammetsafak.com.tr/en/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.

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:

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. **Treat KV as a cache, not the source of truth.** 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. **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; the user doesn't wait, and doesn't see the stale value for long, either.
4. **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.
5. **Accept KV's global eventual consistency.** KV 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 — go to origin or choose a different consistency model.

**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://www.muhammetsafak.com.tr/en/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://www.muhammetsafak.com.tr/en/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://www.muhammetsafak.com.tr/en/just-ask/secretless-ci-cd-with-aws-iam-roles-and-oidc/) — Just Ask