Caching Strategies

What Are Caching Strategies?

If a product's price is read from the database 10,000 times an hour and changes once a day, the system does nearly all of that work for nothing. A caching strategy decides how much of that repeated work to skip, and how much out-of-date data the product can tolerate in exchange.

Every cache trades freshness for speed. A copy held in memory answers far faster than a database query, but it can fall behind the source the moment the source changes. The strategy is the set of choices that manages that gap, from when data enters the cache to when it expires.

Caching happens at several layers at once. A browser keeps files it has already downloaded, a CDN keeps pages and assets close to users, an application cache such as Redis keeps database results in memory, and the database keeps recently used data in its own memory. Each layer needs its own rules, and a stale copy at any one of them is what the user ends up seeing.

Why Do Caching Strategies Matter?

• They decide how far a system scales before it needs more hardware. When most reads are answered from cache, the database handles only the misses and the writes, so the same database can serve far more users.

• They keep repeated work away from the slowest parts of the system. Database queries and third-party API calls are usually the slowest and most expensive things an application does. A cache in front of them absorbs repeated requests, including traffic spikes that would otherwise overload them.

How Do Caching Strategies Work?

• Cache-aside (lazy loading). The application checks the cache first. On a miss, it reads from the database and writes the result into the cache for next time. AWS describes this as the most prevalent form of caching.

• Write-through. Every write to the database also updates the cache, so recently written data is already cached when someone reads it.

• Write-behind (write-back). Writes land in the cache first and are saved to the database asynchronously, often in batches. Writes become fast, but the cache and the database disagree for a short time, and queued writes are at risk if the cache fails before saving them.

• Time to live (TTL). Each cached entry gets an expiry time. AWS recommends a TTL on every key except those kept current by write-through, as a safety net for data that would otherwise stay stale.

• Eviction. When the cache fills up, it removes entries according to a policy. A common one, least recently used (LRU), drops the entries nobody has asked for in the longest time.

• HTTP caching. For browsers and CDNs, the server sets the rules in response headers. Cache-Control: max-age says how long a copy stays fresh, and an ETag lets the browser ask whether its copy is still valid instead of downloading the file again.

What Tools Do Teams Use for Caching?

In-memory data stores. Redis, Valkey, and Memcached hold application data in memory for very fast lookups. Valkey is a BSD-licensed alternative to Redis, launched under the Linux Foundation in March 2024 after Redis changed its license.

Content delivery networks. Cloudflare, Fastly, and Amazon CloudFront cache pages and static files at locations close to users, following the HTTP caching headers the origin server sends.

Client-side caching. Service workers let a web app manage its own cache for offline use, and libraries such as TanStack Query cache API responses inside the app.

What Are the Key Characteristics of Caching Strategies?

• Bounded size. A cache is deliberately smaller than the data behind it, so every strategy has to decide what to drop when space runs out.

• Hit ratio as the main health signal. The share of requests answered from cache shows whether a strategy is working. A falling hit ratio usually means entries expire too early or the cache is too small.

• Shared or private. MDN distinguishes private caches, tied to one user's browser, from shared caches such as CDNs that serve many users. Personalized responses belong only in private caches, marked with Cache-Control: private.

• Versioned URLs for static files. Changing a file's URL whenever its content changes, as in bundle.v123.js, lets browsers keep it for a long time without ever serving an old version. MDN calls this a common best practice.

What Are the Benefits of Caching Strategies?

• Faster responses. Data served from memory or a nearby CDN skips the database query or the long network trip to the origin server.

• Lower infrastructure cost. Fewer database queries and less traffic to the origin mean smaller database instances and lower bandwidth bills.

• Better resilience. A CDN or cache can be configured to keep serving the last good copy while the origin server is slow or down, so a backend incident does not always become a user-facing outage.

• Staying within third-party limits. Caching responses from rate-limited or pay-per-call APIs keeps an application under its quota and its bill predictable.

What Are the Challenges of Caching Strategies?

• Invalidation. When source data changes, every cached copy of it has to be updated or removed. Deleting cache keys on every write keeps data fresh, but ties every write path to the cache, and one missed path leaves stale data nobody notices until a user reports it.

• Thundering herd. When a popular entry expires, many requests can miss at once and all hit the database together. AWS suggests prewarming the cache and adding randomness to TTLs, which spreads out expiries but makes cache timing harder to predict and test.

• Leaking personal data. A shared cache that stores a personalized page can show one user's data to another. Marking those responses private prevents the leak, but those pages then lose the CDN offload the rest of the site gets.

• Harder debugging. With several cache layers, a report of wrong data can trace back to any of them. Cache-status headers and logging make the source traceable, but add instrumentation work at every layer.

What Is the Difference Between Cache-Aside and Write-Through Caching?