Five Caching Strategies, and When Each One Will Burn You

I have seen Redis added to a system the way people add salt to food, instinctively, before tasting anything. The cache goes in, latency drops, everyone is happy, and then three months later someone files a bug because users are seeing stale data they swear they updated. The cache was the problem. Not because caching is bad, but because the wrong strategy was picked for how the system actually reads and writes.

There are five patterns worth knowing. They are not interchangeable.

What is Cache?

A temporary storage layer that sits between your application and your database. The goal is to avoid repeated expensive database calls by serving frequently accessed data from memory.

There is no universally correct strategy. The right choice depends on whether your system is read-heavy, write-heavy, or whether data consistency is the priority.

---

1. Cache Aside (Lazy Loading)

Flow:

1. App checks the cache
2. On a hit, return data
3. On a miss, app goes to the DB itself, stores the result in cache, returns it

The app owns all three steps. The cache is passive.

On write: invalidate or update the cache entry. Invalidation is usually safer.

Best for: read-heavy data that does not change constantly (user profiles, product configs, catalog data)

Tradeoffs:

• First request after a miss always pays the full DB cost
• Simultaneous misses on the same key all hit the DB at once (thundering herd)
• Cache-check logic is scattered in application code

---

2. Write Through

Flow: app writes to cache, cache synchronously writes to DB, response returns only after DB confirms

Best for: low write frequency with strict read freshness requirements (admin panels, financial dashboards)

Tradeoffs:

• Higher write latency because of two sequential synchronous writes
• Cache pollution: data that is never read still gets cached on every write

---

3. Read Through

Flow:

1. App reads from cache only, never touches DB directly
2. On a miss, the cache layer fetches from DB, populates itself, returns data

The cache owns the DB interaction, not the app. This simplifies application code.

Best for: read-heavy workloads where you want to keep DB access out of application code (newsfeeds, product listings)

Tradeoffs:

• Writes typically bypass the cache and go straight to DB, so cached data goes stale immediately after a write
• Staleness window is controlled by TTL, which may not be acceptable for all data types
• Cold start always pays the full DB cost

---

4. Write Back (Write Behind)

Flow:

1. App writes to cache
2. Cache acknowledges success immediately
3. Cache flushes to DB asynchronously later

Best for: write-heavy workloads where throughput matters more than durability (analytics, counters, logging)

Tradeoffs:

• Data loss risk if cache crashes before flushing. How much you lose depends on cache persistence config (Redis with no persistence can lose everything since the last flush)
• Not suitable for financial, order, or any data where losing a write is unacceptable

Difference from Write Through: Write Back acknowledges before the DB write. Write Through waits for the DB to confirm. Write Back trades durability for speed. Write Through trades speed for consistency.

---

5. Write Around

Flow:

1. App writes directly to DB, cache is skipped entirely
2. On read, app checks cache first
3. On miss, fetches from DB and populates cache

Best for: data that is written once and read infrequently (audit logs, exported reports, archived records)

Tradeoffs:

• First read after any write is always a cache miss because the cache was never populated at write time
• Increased read latency until the data gets cached through normal read traffic

Difference from Cache Aside: Cache Aside can update or invalidate the cache on write. Write Around deliberately skips the cache on every write, assuming the written data will not be read back soon.

---

The summary that actually holds up

Cache Aside and Read Through are for read-heavy systems, but they handle cache population differently and the write behavior of Read Through is easy to overlook. Write Through and Write Back are both write-aware strategies, but they are opposites in terms of what they trade off: Write Through trades write speed for consistency, Write Back trades durability for speed. Write Around is for data you write but rarely read back.

The mistake is not reaching for one of these. The mistake is not thinking about what your system actually does before picking one.