DEV Community: Muralidharan Lakshmanan

Cache Patterns Every Engineer Should Know

Muralidharan Lakshmanan — Sat, 15 Aug 2026 22:33:53 +0000

In the previous parts of this series, we answered two questions: why do we need caching, and where should the cache live?

Now we need a more practical one:

How should the application actually interact with the cache?

This is where caching patterns come in. A cache is not just a box where we put data. We need a strategy for reading data, handling misses, writing data, updating cached values, and dealing with staleness. Different patterns solve these problems differently. Let's look at the most common ones.

1. Cache-Aside — the most common pattern

Let's start with Cache-Aside, also called lazy loading. The basic idea: the application is responsible for checking the cache and loading data on a miss.

GET /products/123

Application → Cache → HIT → Product. Done.

Application → Cache → MISS
                        ↓
                    Database
                        ↓
                  Store in cache
                        ↓
                    Response

Product product = cache.get("product:123");

if (product == null) {
    product = database.findProduct(123);
    cache.put("product:123", product);
}

return product;

The next request can be served from the cache.

Cache-Aside is popular because it's simple. The application explicitly decides what to cache, when to cache it, what TTL to use, what to do on a miss, and when to invalidate it. It also works with almost any cache technology.

The downside is that the application now carries caching logic. Developers need to remember the check-fallback-populate sequence, and if several services do this independently, that logic tends to get duplicated. Still, Cache-Aside is often the best starting point.

2. Read-Through — let the cache do the loading

Read-Through moves that responsibility away from the application. Instead of the application saying "if the cache misses, I'll query the database," it simply says "give me the data." The cache handles the miss itself.

The application code gets simpler:

product = cache.get("product:123");

If the cache doesn't have it, the cache layer knows how to retrieve it. The application doesn't need to know as much about the underlying data source, which can produce cleaner application code.

The catch is that not every cache supports this natively — you need a caching layer or framework that knows how to load the missing data, which means more abstraction and configuration. Read-Through can be elegant, but Cache-Aside is usually easier to understand and implement directly.

3. Write-Through — write to the cache and database together

So far we've mostly talked about reads. But what happens when data changes? Suppose a customer updates their address. Now the database and the cache both need to reflect the new value.

With Write-Through, a write goes through the cache, and the cache updates the underlying data store as part of the same operation:

Update customer address
          ↓
       Cache
          ↓
      Database

The main benefit is freshness — the cache is updated as part of the write path, so the system reduces the chance of serving an old value. The cost is that writes become more expensive: instead of Application → Database, a write now involves Application → Cache → Database. We're trading write performance and complexity for better cache freshness.

4. Write-Behind — make writes fast

Now the opposite approach. What if writes are extremely frequent — say, 50,000 updates per second? Writing every one immediately to the database may be expensive.

With Write-Behind, the cache accepts the update first and the write returns immediately. The database catches up later, asynchronously.

This can make writes extremely fast. But there's a serious trade-off: what happens if the cache crashes before the update reaches the database? Potentially, data loss.

That's why Write-Behind shouldn't be treated as simply "a faster Write-Through." It's a fundamentally different consistency and durability model. It works best when eventual persistence is acceptable, the cache has reliable durability mechanisms of its own, updates can be replayed or recovered, and extreme write performance genuinely matters.

5. Refresh-Ahead — don't wait for the cache to expire

Here's another problem. Suppose product:123 is cached with a TTL of 10 minutes, and thousands of users are requesting it. At minute 9, every request is a hit. At minute 10, the cache expires — and thousands of requests can arrive at the database at the same instant.

We touched on this earlier in the series. It's commonly called a cache stampede or thundering herd.

Refresh-Ahead tries to avoid it. Instead of waiting for the value to expire, the system refreshes it shortly beforehand, while the existing cached value keeps serving requests in the meantime.

Imagine a flight-search application where a popular route is requested thousands of times. Instead of letting the cache expire completely, the system refreshes the data once it has, say, 30 seconds left. The next request doesn't have to wait for a database call — it just gets served from an already-fresh cache.

6. Comparing the patterns

Pattern	Who handles the miss?	How writes work	Main benefit
Cache-Aside	Application	Application manages writes	Simple and flexible
Read-Through	Cache	Depends on implementation	Cleaner application code
Write-Through	Cache layer	Cache and database together	Better freshness
Write-Behind	Cache	Database updated later	Very fast writes
Refresh-Ahead	Cache / background process	Usually a normal write strategy	Reduces cold misses

There is no universally "best" pattern. The workload determines the answer.

7. A real-world example

Let's imagine an e-commerce product with a name, description, price, inventory count, and reviews. Should all of it use the same caching pattern? Probably not.

The description changes rarely, so plain Cache-Aside with a one-hour TTL is fine. The price changes more often, so we pair Cache-Aside with explicit invalidation the moment it changes. Inventory is more sensitive — a stale number could let a customer buy something that's no longer available, so a much shorter TTL, or skipping the cache in some parts of the workflow, makes more sense. Recommendations can be expensive to calculate, which makes them a good candidate for Cache-Aside plus Refresh-Ahead.

That's an important lesson: don't choose one caching pattern for your entire system. Choose the pattern based on the behavior of the data.

8. The hidden complexity: cache invalidation

Suppose the database has product:123 at $899, but the cache still has $999. A caching pattern doesn't automatically solve this — you still need to decide what happens to the cache when the database changes.

The common answers are to delete the entry and let the next request reload it, update the cached value directly, let the TTL expire naturally, or invalidate the cache in response to a published event when the database changes.

This is a big enough topic that the next part of this series is devoted entirely to it.

9. Which pattern should you start with?

If you're designing a new application and aren't sure what to use, don't reach for the most sophisticated pattern first. For many read-heavy applications, plain Cache-Aside in front of the database is an excellent starting point.

Then measure. Is the hit ratio good? Is database load actually reduced? Are misses expensive? Are hot keys causing problems? Is stale data acceptable? Are writes becoming a bottleneck? Only once you have answers should you introduce something more sophisticated.

10. The engineer's mental model

Here's a short way to hold all five patterns in your head at once:

Cache-Aside — "I'll manage the cache myself."
Read-Through — "The cache will load missing data for me."
Write-Through — "When I write, update the cache and the source together."
Write-Behind — "I'll make the cache the fast write point and persist later."
Refresh-Ahead — "Don't let popular data go cold if I can refresh it proactively."

Once these five ideas are second nature, most caching architectures become much easier to reason about.

What's next

We've now covered why caching exists, how it actually works, where it should live, and the patterns that govern how an application talks to it.

But there is one caching problem that almost every engineer eventually runs into:

How do you make cached data disappear when the real data changes?

That's cache invalidation — often called the hardest problem in caching — and it's next.

Which pattern is running in your production system right now, and did your team choose it deliberately or inherit it? Curious to hear in the comments.

Where Should the Cache Live?

Muralidharan Lakshmanan — Fri, 14 Aug 2026 22:24:26 +0000

Earlier in this series, we established why caching exists, then looked at how a cache works — memory, key-value storage, TTL, eviction, locality, and performance.

Now comes an architectural question:

Where should the cache actually live?

This is where caching gets more interesting.

A cache doesn't have to be one Redis server sitting between your application and database. In a modern system, you might have several caching layers stacked between the user and the source of truth.

The closer the cache is to the user or application, the less work the request needs to do.

But there's a catch: every additional caching layer introduces another copy of your data — and another thing you have to manage.

1. Browser cache: the fastest cache you don't own

Let's start at the edge closest to the user: their browser.

Suppose you visit a website and download logo.png, app.js, styles.css, some fonts, and a set of product images. Do we really need to download those files every time you visit?

No. The browser can store them locally.

Browser
   │
   ├── Do I already have it?
   │
   └── YES → use the local copy

In many cases the server doesn't even need to process the request. That's an enormous performance improvement, because the network disappears from the critical path entirely:

Without browser cache:     With browser cache:

User                       User
  ↓                          ↓
Internet                   Browser cache
  ↓                          ↓
Server                     Response
  ↓
Response

But there is a problem

You don't completely control the browser's copy.

Imagine you release a new version of your JavaScript application. A user might still be holding app.js version 1 while your server is serving version 2.

This is why cache-control headers, versioned filenames, and content hashing matter so much:

app.abc123.js
app.def456.js

When the content changes, the filename changes too. The browser can safely cache the old version forever, because the new application asks for a different file.

2. CDN: bringing the cache closer to the user

Now imagine your application runs in Virginia, but your users are in New York, California, London, Singapore, and Tokyo. If every image request travels all the way to your application servers, you're doing unnecessary work.

This is where a Content Delivery Network (CDN) helps — it places cached copies at locations closer to users.

A user in Tokyo doesn't necessarily need to travel all the way to your origin server:

User → Tokyo edge → Response

instead of

User → Tokyo → Internet → Origin → Database

That's not just a latency optimisation. It can also dramatically reduce traffic hitting your origin infrastructure.

What commonly belongs in a CDN: images, JavaScript, CSS, fonts, videos, static files, and sometimes API responses.

But here's another important lesson: not everything should be cached at the CDN. Highly personalised or sensitive data requires much more careful handling.

3. Application cache: keep data close to your code

Now let's move inside the application.

Suppose your application frequently needs this information:

US → United States
IN → India
CA → Canada
UK → United Kingdom

Does it make sense to query a database every time? Probably not. You could keep this in memory instead, where retrieval is extremely quick. There is no database call. There isn't even a network call.

This is sometimes called a local cache or in-process cache.

Local cache:          Distributed cache:

Application           Application
    ↓                     ↓
  Memory              Network
    ↓                     ↓
  Result              Distributed cache
                          ↓
                      Result

The local cache wins on raw latency. But now we have a problem.

4. The problem with local caches

Imagine you have three application servers, each with its own cache. All three are holding product:123 at $999.

Now someone changes the product price to $899. The instance that handled the write updates its own copy. The other two don't automatically know anything happened.

The cache is fast. But the copies aren't necessarily consistent.

This is one of the fundamental trade-offs in caching:

The closer the cache is to the application, the faster it can be — but the harder multiple copies can be to keep consistent.

5. Distributed cache: one shared cache

Instead of giving every application instance its own cache, we can introduce a shared one, as shown on the right side of the diagram above. All three application servers now read the same cached data, and the divergence problem goes away.

But we have introduced another trade-off. The cache is no longer inside the application, so instead of:

App → Memory

we now have:

App → Network → Cache

Still much faster than many database operations — but not free. And now the cache itself needs monitoring, scaling, failover, capacity planning, security, backup and recovery considerations, and operational ownership.

We're starting to see an important pattern. Caching isn't free. It moves cost around.

6. Database caching

Here's something many developers forget: the database itself is already using caches.

Databases typically keep frequently accessed data, indexes, pages, and other structures in memory. So when your application executes:

SELECT * FROM products WHERE id = 123;

the database may not need to read from physical storage at all. It may already have what it needs in memory.

Application
     │
     ▼
 Database
     │
     ├── Memory cache → HIT
     │
     └── Disk         → MISS

This matters because it means adding an application cache isn't automatically the first thing you should do. Sometimes the database is already performing well. Sometimes a missing index, an inefficient query, or an excessive number of round trips is the real problem.

Before adding a cache, understand the bottleneck.

7. Putting the layers together

Now let's look at a realistic request. A user opens a product page, and the request may encounter several layers before anything answers it.

What makes layered caching powerful is that different requests stop at different places:

Only when everything misses do we reach the database — and then the response travels back up, populating the layers on its way, so the next request stops sooner.

8. But should we add every layer?

Absolutely not. This is where caching becomes dangerous.

It is tempting to think:

Browser + CDN + Local cache + Redis + Database cache = maximum performance

Not necessarily. Every layer introduces complexity. Imagine a value that exists in the browser, the CDN, a local cache, Redis, and the database. Now ask:

Which one is correct?
If the value changes, which layers need to be invalidated?
If Redis goes down, does the application continue?
If the CDN serves stale content, is that acceptable?
If the local cache holds an older value, how do we update it?

Suddenly our simple performance optimisation has become a distributed-systems problem.

9. So where should you put the cache?

Cache location	Best for	Main trade-off
Browser	User-specific and static resources	Limited server control
CDN	Global, static content	Invalidation and personalisation
Local application memory	Tiny, frequently used data	Multiple copies
Distributed cache	Shared application data	Network and infrastructure
Database cache	Database internals	Doesn't eliminate DB requests

There isn't one universally correct location. The right answer depends on what you're caching.

10. A simple decision framework

Before adding a cache, ask four questions.

Who needs this data?
Only one application instance? A local cache might work. Every instance? Consider a distributed cache. Every user? A CDN or browser cache may be appropriate.

How frequently does it change?
Rarely — longer TTLs become possible. Frequently — you need a stronger invalidation strategy.

How expensive is the original operation?
If the database query takes 2 ms, caching may not be worth much. If it takes 500 ms and happens thousands of times per second, caching becomes very interesting.

How much stale data can we tolerate?
This is perhaps the most important question. A few minutes of staleness is probably fine for a profile picture or a product description. Inventory counts are a harder call. A bank balance has very different requirements altogether.

The answer to that last question determines the caching strategy more than any benchmark will.

The bigger lesson

Caching isn't just about where to store data. It's about deciding:

How far are we willing to move away from the source of truth in exchange for speed?

The closer the cache is to the user, the faster the response can become. But the farther we move from the source of truth, the more carefully we need to think about freshness, invalidation, consistency, failures, observability, and operational complexity.

That's why experienced engineers don't simply ask "should we use Redis?" They ask:

"What problem are we trying to solve, and which caching layer solves it with the least complexity?"

What's next

So far we've covered why caching exists, how caching works, and where caching lives.

But we still haven't answered a critical question: when the application reads or writes data, exactly how should the cache participate?

Should the application talk to the cache first? Should the cache automatically load missing data? Should writes go to the cache first? Should the cache write to the database later?

These are caching patterns, and choosing the wrong one can create subtle production problems. That's where we'll go next.

How many caching layers does your production system actually have — and could you name what invalidates each one? I'd genuinely like to know how many people can answer that second part.

How Caching Actually Works

Muralidharan Lakshmanan — Thu, 13 Aug 2026 01:58:42 +0000

Previously in this series, we looked at why caching exists. It can reduce latency, lower database load, and help an application handle more traffic.

But there is a natural next question:

What actually happens inside a cache?

To answer that, we need to understand where the data lives, how we find it, how long it stays there, what happens when the cache fills up, and why location matters.

Once these concepts click, technologies such as Redis, Memcached, browser caches, CDNs, and application-level caches become much easier to reason about.

Memory vs. disk: why is a cache so fast?

When people say a cache is fast, they are often talking about memory — specifically RAM.

A database may use memory too. Modern databases aggressively cache data in RAM. The point is not that databases are always slow or that caches are always in RAM. The point is that a purpose-built cache often keeps frequently used data and the lookup path extremely simple.

Memory is fast, but it is limited and usually treated as less durable than disk storage. Disk gives us much more capacity and persistence, but accessing data from disk or through a more complex storage path generally costs more time.

Cache     →  optimise for fast access
Database  →  optimise for durable, structured, reliable storage

This is a mental model, not an absolute rule. Modern systems blur the boundary: databases use RAM caches, operating systems cache disk pages, and some caches can persist data.

The key-value model

Most caching systems become easier to understand when you think of them as a giant dictionary.

key:    "user:123"
value:  { "name": "John", "country": "USA" }

The application knows the key. The cache uses that key to find the value quickly.

Good cache keys are predictable and unique enough to avoid collisions:

user:123
product:987
product:987:details
recommendations:user:123

Key design becomes increasingly important as systems grow. Poorly designed keys can cause collisions, make invalidation difficult, or create unexpected hot spots.

TTL: how long should cached data live?

A cache cannot keep every value forever. At some point, cached data needs to expire. That is where TTL — Time To Live — comes in.

weather:atlanta  →  { ... }   TTL = 5 minutes

For the next five minutes, requests can use the cached value. After the TTL expires, the entry is considered expired and the application may need to fetch fresh data.

TTL is a trade-off. A very short TTL keeps data fresh but causes more cache misses. A very long TTL improves cache efficiency but increases the chance of serving stale information.

There is no magic TTL. A stock price may need a very different freshness strategy from a country-code lookup table. A product description may tolerate minutes or hours of staleness, while an account balance may require much stricter rules.

The right TTL comes from the business requirement — not from a universal caching rule.

What happens when the cache is full?

Imagine your cache has a fixed amount of memory and every new item wants a place. Eventually, there is no room.

The cache needs a way to decide which existing item should be removed. This is called an eviction strategy.

Think of it like a small desk. When the desk is full and a new document arrives, you need a rule for deciding which old document gets thrown away.

Policy	Full name	What it looks at
LRU	Least Recently Used	Recency — how long since this was last touched
LFU	Least Frequently Used	Frequency — how often this has been accessed
FIFO	First In, First Out	Insertion order — how long this has been here

The distinction sounds academic until you apply all three to the same cache at the same moment. Consider a cache that is full at three entries when a fourth item arrives:

Same data, same instant, three different victims. FIFO throws out the entry that has been accessed the most, because it happened to arrive first. LFU throws out the entry that was just used a minute ago, because it hasn't accumulated many accesses yet.

Neither is a bug. Each policy encodes an assumption about which data you are likely to need next, and that assumption is either a good fit for your access pattern or a bad one. Real systems may offer additional policies or combinations.

The important principle is this: when capacity is limited, the cache needs a policy for deciding what stays.

Cache locality: keep data close

Another important idea is locality.

Imagine an application server in Atlanta accessing a nearby cache versus repeatedly making requests to a cache across the country. Both may work, but the network path matters.

Application  →  nearby cache   →  response
Application  →  distant cache  →  network  →  response

Every network hop introduces latency and another possible failure point.

This is why system designers often try to keep frequently accessed data physically or logically close to the application that needs it. The same idea appears at many layers:

CPU caches keep data close to the processor
Browser caches keep content close to the user
CDNs keep content close to geographic regions
Application caches keep frequently used data close to the application

Locality is not only geography. It can also mean reducing unnecessary network calls and expensive processing.

Understanding the performance numbers

Saying "the cache is fast" is not enough. You need to understand what fast actually means.

Latency

Latency measures how long an individual operation takes.

Cache lookup:    2 ms
Database query:  80 ms

These are illustrative numbers, not universal benchmarks. Real measurements depend on hardware, network distance, workload, serialization, concurrency, and many other factors.

Throughput

Throughput is how much work the system can handle over time — for example, requests per second.

5,000 cache operations/sec

A cache with low latency but insufficient throughput can still become a bottleneck.

Cache hit ratio

The hit ratio tells us how often requested data is found in the cache.

1,000 requests
  900 hits
  100 misses

Hit ratio = 90%

A high hit ratio is generally useful because more requests avoid the backend. But it is not a universal score of success.

Imagine a cache with a 99% hit ratio where each cache lookup is expensive, or where the 1% of misses trigger extremely costly database operations. The hit ratio alone does not tell the whole story.

Look at the numbers together

latency + throughput + hit ratio + memory usage + backend load

For example, after introducing a cache, API latency might drop from 150 ms to 40 ms and database CPU might fall significantly — but cache memory could be growing too quickly. That is not simply success or failure; it is a signal for the next design decision.

Putting it all together

Let's walk through one request:

User requests product 987
Application builds the key: product:987
Cache checks the key
Hit? Return the cached value
Miss? Query the database
Store the result in the cache
Apply a TTL
If the cache becomes full, an eviction policy decides what leaves

Caching is no longer just "put data somewhere fast." It is a small system with rules:

Where is the data?
How do I find it?
How long does it live?
What happens when it expires?
What happens when there is no space?
How fast is the lookup?
What happens when the cache fails?

Those questions are the foundation of good cache design.

Caching is a layer, not just a storage box

One useful mental model is to think of caching as a layer between the application and the source of truth.

User
  ↓
Application
  ↓
Cache      ← fast, temporary copy
  ↓
Database   ← durable source of truth

The cache exists to reduce the cost of repeatedly reaching the source of truth.

That distinction becomes very important when we start discussing consistency, invalidation, and failure handling.

What's next

So far, we have looked at what caching solves and how a basic cache works.

The next question is architectural: where should the cache live?

Should it live inside the application? On a separate server? At the edge? In the browser? In front of a database?

Next in this series, we'll explore the different places caching can exist — from browser caches and CDNs to application and distributed caches — and understand why choosing the right layer can be just as important as choosing the caching technology.

Which eviction policy does your cache actually use — and do you know why that one? I'd be curious to hear in the comments whether it was a deliberate choice or the default that shipped with the tool.

Caching Is Simple... Until It Isn't

Muralidharan Lakshmanan — Wed, 12 Aug 2026 01:55:57 +0000

If you have worked on software systems for a while, you have probably heard this advice:

"Just add a cache."

It sounds simple.

Your application is slow? Add a cache.
Your database is getting too many requests? Add a cache.
Your API needs to handle more users? Add a cache.

And surprisingly often, it works.

But caching is one of those things that looks incredibly simple when you first learn it — and becomes much more interesting once you use it in a real production system.

Because the moment you add a cache, you are no longer dealing with just one question: "How can I make this faster?"

You also have to think about what to cache, how long to keep it, what happens when the data changes, what happens when the cache is unavailable, how much memory it will use, and what happens when thousands of users request the same uncached data.

That's when caching stops being simple.

What problem does caching actually solve?

Imagine you have an application that needs to display a user's profile.

User  →  Application  →  Database  →  Application  →  User

The application receives the request, queries the database, gets the data, and sends it back.

GET /users/123

SELECT * FROM users WHERE id = 123;

Nothing is wrong with this. But what happens if 10,000 requests ask for the same information?

You could end up executing thousands of database queries for data that hasn't changed.

That's where caching comes in. Instead of asking the database every time, we keep frequently requested data in a faster storage layer.

User  →  Application  →  Cache  →  Database (only when necessary)

If the data is already in the cache, we don't need to contact the database. That is the basic idea.

A real-world analogy

Think about a restaurant. Imagine you are a waiter and customers frequently ask for the restaurant's menu.

Approach 1: Go to the kitchen every time.
Every time someone asks, "Can I see the menu?", you walk to the kitchen, find the menu, bring it back, and hand it over. Now imagine doing that 500 times. It would be ridiculous.

Approach 2: Keep the menu at the table.
Instead, you keep a copy of the menu on every table. When someone asks for it, you simply point to the menu already sitting there. Much faster.

In the restaurant	In your system
The customer	The user
The waiter	The application
The kitchen	The database
The menu on the table	The cache

We keep frequently needed information closer to where it is needed.

Latency: why does caching make things faster?

One of the biggest reasons to use caching is latency — the time it takes for something to respond.

Operation	Example latency
Cache request	~2 ms
Database request	~80 ms

The numbers above are illustrative, not universal benchmarks. The important point is that an in-memory cache can often respond much faster than a database path that involves network communication, query processing, indexes, joins, disk I/O, connection management, and other work.

When you multiply that difference by thousands or millions of requests, the impact becomes significant.

Caching also reduces database load

Speed is only part of the story. Caching can also protect your database.

Without caching:  100,000 requests  →  potentially 100,000 database queries
With caching:     100,000 requests  →  cache  →  perhaps only a handful of queries

Imagine an e-commerce site where a popular product is requested thousands of times. Product name, description, specifications, and other relatively stable information may be good candidates for caching.

The database gets fewer requests. The application gets faster responses. The system can potentially handle more traffic.

Cache hit vs. cache miss

Two terms appear everywhere when talking about caching: cache hit and cache miss.

Cache hit

A cache hit happens when the data you are looking for is already in the cache.

Application  →  Cache  →  "Found it!"  →  Return data

The database is not needed for that request.

Cache miss

A cache miss happens when the requested data is not in the cache.

Application  →  Cache  →  "Not found"  →  Database  →  Cache  →  Return data

The first request is slower, but the result can be stored in the cache so future requests can be faster.

This is the cache-aside pattern, and it's worth noticing who is in charge: the application checks the cache, the application falls back to the database, and the application writes the result back. The cache itself knows nothing about your database.

So why not cache everything?

This is where things get interesting. If caching makes things faster, why not simply cache everything?

Because caching has a cost. A cache requires memory, infrastructure, monitoring, maintenance, and additional application logic. And perhaps the biggest problem is stale data.

Imagine you cache this product:

{ "product": "Laptop", "price": "$999" }

The cache keeps it for 30 minutes. Five minutes later, the real price changes from $999 to $899. The cache still contains $999.

Now the application may show the user the wrong price.

This is the classic caching problem: how do you keep cached data reasonably fresh?

Possible approaches include short expiration times, explicit invalidation, event-driven updates, versioned cache keys, and other strategies. Each one introduces additional design decisions.

Caching can actually make a system worse

Caching isn't automatically good. A poorly designed cache can create new problems.

For example, imagine your application caches millions of objects without considering memory usage:

Cache memory → 100%  →  Evictions  →  Cache misses  →  More database requests

Or imagine the cache suddenly becomes unavailable:

Normal:   10,000 req/sec  →  Cache  →  Database sees a manageable load
Failure:  10,000 req/sec  →  Database

If the database is suddenly exposed to traffic that the cache normally absorbs, the database can become the next bottleneck.

Other problems include cache stampede, hot keys, invalidation issues, inconsistent data, memory pressure, network latency, cache availability, and serialization/deserialization overhead.

We'll explore these problems later in the series.

The important question isn't "should I use caching?"

A better question is:

"What should I cache, why should I cache it, and what happens when the cache is wrong or unavailable?"

That shift in thinking is important.

Often good candidates:

Frequently requested data
Relatively stable data
Expensive database queries
Expensive computations
External API responses
Configuration or reference data

Often poor candidates:

Data that changes constantly
Data that requires strict real-time consistency

That second list isn't a hard "never" — it may just require a more carefully designed caching strategy. There is no universal answer.

Caching is a trade-off


Performance	↔ Complexity
Freshness	↔ Speed
Memory cost	↔ Database cost
Availability	↔ Consistency

That is the real story of caching. A cache can make a system faster and reduce database pressure, but it also introduces another component and another set of failure modes.

And that's why caching is simple... until it isn't.

What's next

Next in this series, we'll go one level deeper and look at how caching actually works: where cached data lives, memory vs. disk, TTL (time to live), cache keys, eviction strategies such as LRU and LFU, and what happens when a cache runs out of memory.

Once you understand those fundamentals, technologies such as Redis and Memcached become much easier to understand.

Because before learning which caching technology to use, it's worth understanding what problem we're actually trying to solve.

What's the worst caching bug you've shipped? I'm collecting war stories for a later post in this series — drop yours in the comments.