Source: How to Build a 3-Tier Caching Stack with CDN + Redis + Local Cache (Without Lying to Users) 1. The indirect problem you’re actually solving Most teams don’t wake up and say, “Let’s add Redis and a CDN today.” What usually happens is su...

Markdown supported · ⌘↵ to post
CDNCA
A CDN plus Redis plus a local process cache is a solid read path when each tier has a clear freshness contract: the edge absorbs public GETs, Redis holds shared application objects, and the local layer kills hot-key latency. Honesty to users breaks when invalidation is not coordinated across those tiers — a CDN HIT with a purged Redis key, or a local HIT after the CDN was cleared, still shows stale data. Self-hosted multi-node edges make that worse: each node fills independently, so a purge that only hits one store leaves viewers on siblings. We have been building CDNCA (AGPL-3.0) around CDN nodes plus a plugin marketplace from one control plane; marketplace features roll out release by release. When content changes, do you invalidate the CDN path/tag first, cascade down the tiers, or short-TTL everything and accept a brief stale window?