When people talk about caching, it is easy to think it just means storing data temporarily so it can be fetched faster later. In reality, caching has its own patterns and structures, like everything else in software design. This article walks through four of the most common ones.

Read-Through

In this pattern, the cache layer sits in front of the data source. When a request comes in and the cache misses, the cache itself fetches the data from the source, stores it, and returns it. The caller only ever talks to the cache; it never fetches from the source directly.

Where it shows up. The clearest example is a CDN like Cloudflare. When you request a media asset, the edge layer handles the miss and the fetch from origin on its own. Expiration is usually TTL-based, unless a specific asset changes and you need to control it explicitly with Cache-Control headers.

Write-Through

Here writes go to the cache first, and the cache writes through to the database. The operation is only marked complete once both confirm the write, so the cache and the database stay in sync.

The tradeoff is a dual-write risk: if the cache confirms but the database write fails (or vice versa), the two can end up out of sync, so the implementation needs retry logic or error handling for that case.

Where it shows up. This is less common in WordPress environments, but it is common in tools like Asana. When you move a ticket from “In Progress” to “Completed,” that update is written through to an in-memory layer (like Redis) and to the primary database. That way, if a teammate refreshes their screen a millisecond later, they see the same state.

Write-Behind or Write-Back

This pattern is similar to write-through, but the sync to the database happens asynchronously. That makes writes very fast, but it introduces a real risk: if the cache fails before it flushes, you can lose that data.

Where it shows up. Picture a viral post that gets 50,000 likes in a second, on any platform with that kind of traffic. The system is not going to run 50,000 synchronous writes straight to the database; that would overwhelm the infrastructure. A more likely design is to send that traffic to the cache instead: the counter increments instantly there, and it syncs to the durable database every few seconds. This is a common pattern for that kind of problem, not a confirmed detail of how any specific platform is built.

Cache-Aside or Lazy Loading

This is the pattern most associated with WordPress, and the one used by most traditional monolithic web applications. The application asks the cache for a piece of data (a page, an article, and so on). If it is there, it is returned, and the request is done. If not, the application queries the database, returns the result to the user, and stores it in the cache with a TTL for next time.

It is the simplest pattern to reason about, precisely because the application owns the logic end to end.

One Pattern, Two Strategies?

In the next article, we’ll look at how one pattern can be implemented in different ways depending on the complexity of the system it lives in. Like everything else in software, nothing is ever 100% linear.