Caching

Caching stores the result of a costly operation - a database query, an API call, a computed value - in a fast-access layer so subsequent requests can skip the work. The fast layer is usually memory, either in-process or in a dedicated store like Redis.

Done well, caching slashes database load and response times. Done badly, it serves stale data and creates bugs that are hard to reproduce and isolate.

Why it matters in Engineering: Most read-heavy systems cannot scale without caching. A product page might require a dozen database queries - serving it from cache means the database is only hit on a cold start or data change. The implementation is straightforward; the hard part is deciding when to invalidate. Phil Karlton's observation still holds: cache invalidation is one of the two hard problems in computer science.

Cache Patterns

Cache-Aside
The application checks the cache first. On a miss, it fetches from the database and writes to the cache. The most common pattern. The application owns the cache lifecycle.

Write-Through
Every write goes to the cache and the database simultaneously. Cache stays current, but writes are slower. Good when read consistency matters more than write throughput.

Write-Behind (Write-Back)
Writes land in the cache immediately and flush to the database asynchronously. Write throughput improves, but data can be lost if the cache fails before flushing.

TTL (Time to Live)
How long a cached entry is valid before it expires. Too high risks stale reads; too low negates the performance benefit.

Cache Stampede
When a popular entry expires and many requests simultaneously attempt to rebuild it. Mitigated with distributed locks, probabilistic early expiration, or background refresh.

Gotcha: Cache Invalidation
The hardest part of caching. Event-driven invalidation (invalidate on write) is more correct than TTL alone, but requires tight coupling between the writer and cache layer.