EMZETT.Caches
In short: Intermediate storage that keeps already-fetched data for faster, repeated access.
In more detail: Caches exist at many levels — in the browser (HTML/CSS/JS/images), on DNS resolvers (answers until the TTL expires), in CDNs, or in an application’s database connection. The goal is always to need to query slower original sources (network, database) less often.
In Depth
A useful way to picture it: every cache layer is a trade-off between speed and freshness. The closer a cache sits to the user, the faster it is, but also the greater the risk of delivering outdated data.
- Browser cache: stores static assets (images, CSS, JS) locally on the user’s device — the fastest layer, but separate per device.
- CDN cache: a globally distributed network of servers that keeps content geographically close to the user — e.g. Vercel’s edge network automatically caches static Emzett pages.
- DNS cache: resolvers remember answers until the TTL expires, so they don’t have to walk the entire DNS chain again on every request.
- Application/database cache: e.g. Redis caches for expensive database queries.
Every one of these caches can deliver outdated (“stale”) data if the original data changes before the cache is updated — the fundamental problem of caching is therefore less the caching itself than timely and correct invalidation. There are two basic strategies for this: time-based expiry (the cache automatically discards an entry after a fixed TTL, regardless of whether the original data has really changed) and explicit invalidation (the application actively tells the cache “this entry is now invalid”, e.g. directly after a database update).
Cache coherence as the real problem
With several cache layers at once (browser, CDN, application), the same request can deliver differently up-to-date answers depending on the layer — a user might, for example, still see the old product price in the browser cache, while the CDN has long been delivering the new one. HTTP headers like Cache-Control and ETag control exactly this:
Cache-Control: max-age=3600, must-revalidate
ETag: "a1b2c3d4"
max-age states how long a client may use the response without a new request; must-revalidate then forces a check-back with the server (instead of simply continuing to use the outdated version); ETag is a fingerprint of the content, letting the server efficiently check during this check-back whether anything has actually changed, without retransmitting the entire response (a 304 Not Modified response if not).
An area deliberately NOT cached at Emzett, for example, is the shopping cart state — here even a cache with a lifetime of a few seconds would be a real risk of showing wrong stock levels.