Backend
Caching
Storing computed or fetched results closer to the consumer to cut latency and load — in the browser, a CDN, in-process memory, or Redis, keyed with TTLs. It is often the highest-leverage performance win. The hard parts are the classic two: invalidation (serving stale data) and stampedes when many keys expire together, eased with jitter and locks.
Purpose
Caching stores the result of expensive work — a query, a computation, a rendered page — so repeat requests are served from a fast copy instead of recomputing. It exists to cut latency and load, and is often the single highest-leverage performance optimisation.
When to Use It
Read-heavy data that changes rarely: reference data, session lookups, rendered fragments, API responses. Layers stack — browser, CDN, application memory, and a shared cache such as Redis.
Avoid caching highly personalised or fast-changing data unless you can key and invalidate it precisely.
Trade-offs
The famous hard problems are invalidation (serving stale data) and cache stampedes (many keys expiring at once, hammering the origin). More layers mean more places for staleness and bugs. Done right, the payoff in latency and cost is dramatic.
Implementation
Cache-aside is the common pattern: check the cache, and on a miss load from source and store with a TTL. Add jitter to TTLs and a lock or single-flight to prevent stampedes, and pick an eviction policy such as LRU. For HTTP, use Cache-Control and ETag so browsers and CDNs cache correctly.