Caching Strategies: Browser, CDN, and Application Cache
The Fastest Request Is the One You Never Make
Caching means storing a result somewhere cheaper/closer than its original source, so a repeat request can be answered without redoing the expensive work. The tradeoff is always the same one, at every layer: speed now, versus the risk of serving something stale.
Browser cache: stores a response on the user's own device (Cache-Control header)
CDN cache: stores a response at edge servers close to the user, shared across users
Application cache: stores computed results in memory/Redis on the server itselfCache invalidation - knowing when a cached value is no longer valid and needs refreshing - is famously one of the two hard problems in computer science (the other being naming things, and off-by-one errors). A short, well-chosen expiration time (a TTL) is usually a more reliable strategy than trying to proactively invalidate every cache entry the instant its underlying data changes.
Real example: Dawn's own reader pages are server-side rendered per request today - no application-level cache yet - but a CDN in front of them could safely cache a published lesson page for a few minutes, since lesson content doesn't change second-to-second. The same CDN should NOT cache an authenticated admin API response, since that's specific to one logged-in user and would leak between sessions if cached shared.