Skip to main content
Architecture & Engineering

Caching

Caching stores the result of an expensive operation so subsequent requests can reuse it instead of recomputing it. It is the highest-leverage performance technique available, and the most common source of bugs where users see stale or — worse — another user's data.

Caching works at every layer: the browser, a CDN at the edge, an application cache such as Redis, and the database's own query cache. Each layer removes work from the layers beneath it, which is why a well-cached system can serve orders of magnitude more traffic on the same hardware.

The hard part is invalidation — knowing when cached data has become wrong. Time-based expiry is simple and accepts a window of staleness. Event-based invalidation is precise and easy to get subtly wrong. The most damaging failure mode is caching user-specific data under a key that is not user-specific, which serves one person's data to another; any cache key touching personalised content deserves explicit review.

Codazz builds this in production — Performance & Scaling.

FAQ

Caching
FAQ.

Common questions about caching.

Ask Us Anything

Invalidation is deciding when cached data has become wrong and must be discarded. It is hard because the system storing the cache is usually not the system that changed the underlying data, so it has no direct way to know. Time-based expiry trades correctness for simplicity; event-based invalidation is precise but requires every write path to notify the cache — and missing one produces stale data that is difficult to reproduce.