Caching Strategies: How to Make Systems Fast (Cache-Aside, Write-Through & More)

🔵 Fundamentals · Fresher-friendly → 🔴 goes deep

If load balancing is about doing work on more machines, caching is about not doing the work at all. It's the single highest-leverage trick in system design: a good cache can turn a 200 ms database query into a 1 ms memory lookup and cut your database load by 90%. But caching also hides the famously hardest problem in computer science — keeping cached data fresh. This guide takes you from "what's a cache?" all the way to the patterns and pitfalls senior engineers get grilled on.

What a cache is

A cache is a small, very fast store (usually in RAM, like Redis or Memcached) that holds copies of frequently-used data. Reading from RAM is thousands of times faster than reading from disk or running a database query, so if the answer is in the cache, you skip all that work.

Analogy: instead of walking to the library (database) every time you need a fact, you jot the facts you use most on a sticky note on your desk (cache). The first lookup is slow; the next hundred are instant.

Cache HIT :  answer is in the cache        → return in ~1 ms
Cache MISS:  not in cache → ask the DB,     → slower, but now
             store it, then return          it's cached for next time

The percentage of requests that are hits is your hit ratio. A well-tuned cache might serve 90%+ of reads, meaning the database only sees a trickle of traffic. That's the magic.

Caches are everywhere (the layers)

Caching isn't one thing in one place — it happens at every layer of the journey a request takes:

When people say "add a cache" in system design, they usually mean the application cache — a Redis sitting between your app servers and the database. That's what the rest of this article is about.

The caching patterns (this is the interview part)

🟠 How data gets into the cache and how writes are handled defines the pattern. Know these four:

1. Cache-aside (lazy loading) — the default

The app checks the cache first. On a miss, it reads the database, stores the result in the cache, and returns it. The cache only ever holds data someone actually asked for. This is the most common pattern by far.

READ:  cache hit? return it.
       miss? → read DB → put in cache → return.
WRITE: write to DB, then DELETE the cache key (so next read reloads fresh).

Pro: simple, resilient (if the cache dies, you still hit the DB). Con: the first request for anything is always a miss, and there's a brief window where cache and DB can disagree.

2. Write-through

Every write goes to the cache and the database together, synchronously. The cache is always up to date. Pro: reads are always fresh. Con: writes are a bit slower (two writes), and you cache data that may never be read.

3. Write-back (write-behind)

🔴 Writes go to the cache immediately and are flushed to the database later, in batches. Pro: extremely fast writes, great for write-heavy workloads. Con: risky — if the cache crashes before flushing, you lose data. Used carefully, where some loss is tolerable or durability is added.

4. Write-around

Writes go straight to the database, skipping the cache; the cache is filled only on later reads (cache-aside style). Good for data that's written a lot but rarely read soon after, so you don't pollute the cache with things nobody reads.

When the cache is full: eviction

🟠 Memory is finite, so a cache must throw things out to make room. The policy decides what goes:

• LRU (Least Recently Used): evict whatever hasn't been touched in the longest time. The sensible default — recent data tends to be reused. (Building an LRU is a classic interview question; see design an LRU cache.)
• LFU (Least Frequently Used): evict the least-often-used item.
• TTL (Time To Live): every entry expires after N seconds, whether used or not — a simple, powerful way to bound staleness.

The hard part: staleness & invalidation

🔴 There's a famous joke: "There are only two hard things in computer science — cache invalidation and naming things." Here's the real problem. The moment you copy data into a cache, that copy can become stale if the original changes. Show a user a cached price that's since gone up, and you have a bug — or a lawsuit.

Your tools to manage it:

• TTL / expiry: accept data can be up to N seconds old. Simple and usually enough — pick a TTL your product can tolerate.
• Delete-on-write: whenever the underlying data changes, remove the cache key so the next read reloads fresh (the cache-aside write step above).

The senior mindset: caching is a deliberate trade of freshness for speed. You decide, per piece of data, how stale is acceptable. A trending-posts list can be 60 seconds old; an account balance cannot. Saying that out loud in an interview — "I'd cache the feed with a 60s TTL but never cache the balance" — is exactly the judgment they're testing for.

One more trap: the thundering herd

🔴 A popular cache key expires, and in that instant a thousand requests all miss at once — and all slam the database to rebuild it simultaneously, sometimes crashing it. This is the thundering herd (or cache stampede). Fixes include letting only one request rebuild while others wait, or refreshing hot keys slightly before they expire. Knowing this failure mode exists is a strong senior signal.

What to read next

• CDNs Explained — caching static files near the user
• SQL vs NoSQL — choosing the database behind the cache
• Database Replication — another way to scale reads
• ← The complete System Design guide (hub)

← Load balancing · SQL vs NoSQL →