Loading...
System Design and AI Engineering, by Roni Das. 972 interactive lessons.
Start LearningFoundation · Caching Strategies
A cache that loads missing data from the database by itself, through one loader function, so your code only ever asks the cache. What the loader does when the database fails decides whether an outage shows up as errors or as wrong answers.
In short
A read-through cache is a cache that fetches missing data from the database by itself: your code asks the cache for a key, and on a miss the cache calls a loader function, stores the result and returns it. Your code never talks to the database directly for that data.
In short
A read-through cache is a cache that fetches missing data from the database by itself: your code asks the cache for a key, and on a miss the cache calls a loader function, stores the result and returns it. Your code never talks to the database directly for that data.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Read-Through Cache across a run of lessons, not one page. These 4 alone are about 89 minutes of step-by-step reading, every one with a quiz.
Read-through removes key drift, shape drift and the stampede by construction, and hides one decision. A three second source failure was served as a wrong answer for 297 seconds, with a flat error rate.
The identical function body took 143.874 ms declared VOLATILE and 0.078 ms declared STABLE, which is 1,845 times. The default is VOLATILE, and nothing validates any of these claims.
How key-value databases work, how to design good keys, and how Redis, DynamoDB and etcd compare. Includes a diagram of a GET and SET operation.
Caching a result set freezes it, and the deep pagination it is usually bought to fix disappears when you change the question instead.
all part of
System Design Masterclass
769 lessons · about 282 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
The material has been designed with a lot of effort and dedication. It has covered vast range of topic with sufficient content and diagrams wherever required. It complements well with other system design materials.
You own this course
Continue with Read-Through Cachepay once,
yours for life
A cache is a fast store, usually memory, that keeps copies of data so you do not have to fetch it from a slower place every time. The slower place is called the source. It is often a database, but it can be another service.
In a read-through cache, your application only ever asks the cache. If the cache has the value, that is a hit and it returns it at once. If it does not, that is a miss. On a miss the cache itself calls a function you gave it, called the loader. The loader reads the value from the source. The cache stores it, then hands it back.
So the application has one rule: ask the cache. It does not need to know where the data really lives, or what to do on a miss. That job belongs to the cache and its loader.
Each stored value also gets a time to live, or TTL. That is how long the cache trusts the value before it throws it away and loads it again.
The pattern most teams start with is cache-aside. In cache-aside the application does the work: it checks the cache, and on a miss it reads the database itself, then writes the value into the cache. The cache is just a box on the side.
Both patterns load data only when someone asks for it. The difference is who owns the fetch. In cache-aside, every place in your code that reads this data has its own copy of the logic. In read-through, there is one loader, in one place.
Why does that matter? Because copies drift apart. One call site builds the cache key one way, another builds it slightly differently, and now the same user is cached twice. One sets a TTL, another forgets. The cache-aside lesson measures exactly these problems. With read-through they cannot happen, because there is only one loader to get right.
Moving the fetch into one loader removes three bugs by construction. That means the bug cannot be written any more, which is stronger than fixing it once.
In cache-aside you can get all three right too, but you have to write the code at every call site, and the next person to add a call site can forget.
Here is the catch. In cache-aside, somebody had to write a try block, so the failure behaviour was visible in the code. In read-through, the loader's failure behaviour is a setting inside the cache library. Most teams never choose it. They inherit the default.
There are four things a loader can do when the source fails:
The lesson measured all four. The setup: a read-through cache over 20,000 keys, a 300 second TTL, 2,000 requests a second for 700 seconds. The source failed for three seconds, from second 400 to second 403.
Look at the cache fallback row. It had zero errors. On an error-rate dashboard it looks perfect. It also served 1,307 wrong answers, and the last one went out 297 seconds after the database had recovered. A three second outage became a five minute one, and nothing on the dashboard moved.
The reason is simple. During those three seconds, 199 keys needed loading. Each one stored the default value with the normal 300 second TTL, so the cache trusted that default as long as it would trust a real answer. How long the damage lasts is set by the TTL, not by the outage. A one second blip against a five minute TTL does the same harm.
A default is also hard to spot. An empty list or a zero count is a value your code already knows how to show. The user sees "you have no orders" when the truth is "we could not load your orders". An error, at least, is something the caller can see and handle.
Two of the four policies did well, and they work together.
Most cache libraries support stale-on-error. Caffeine on the JVM has a refresh setting, and NGINX has done the same at the edge for years with proxy_cache_use_stale. The full set of five questions to ask about your cache library, with the measurements behind each answer, is in the Read-Through Cache lesson. That is the best next step if you are about to switch from cache-aside.
Use read-through when many places in your code cache the same kind of data. Every extra call site is another chance for two copies of the logic to disagree, and read-through removes that chance. If only one or two places cache it, cache-aside is fine.
There is one real cost. In read-through, the only way to reach the data goes through the cache. If the cache is down, reads fail. That is why a common setup uses both: a small read-through cache inside your own process, which cannot fail on its own, in front of a shared cache such as Redis that is used cache-aside. A miss in the local cache then never depends on the network cache being healthy.
Read-through only covers reads. For writes, the related patterns are write-through, where every write goes to the cache and the database together, and write-behind, where the cache writes to the database later.
Caffeine (Java)
A LoadingCache takes a CacheLoader, the read-through loader, and refreshAfterWrite can keep serving the old value while a reload runs or fails.
Go singleflight
The golang.org/x/sync/singleflight package gives one load per key with many waiters, the stampede protection a read-through cache builds in.
NGINX
proxy_cache_use_stale serves an expired cached response when the upstream server errors or times out: serve stale, at the web server.
Oracle Coherence and Hazelcast
Both data grids document read-through as a cache loader the grid calls on a miss, so the application never reads the database itself.
No. Both load data only when it is asked for, but in cache-aside your application reads the database on a miss and writes the value into the cache. In read-through the cache does that itself, through one loader function. Read-through removes duplicated logic; cache-aside keeps the failure handling visible in your own code.
A read cache keeps copies of data that is read often, so repeat reads come from fast memory instead of the database. Read-through is one way to fill a read cache: the cache loads a value from the source the first time it is asked for, then serves it from memory until its TTL runs out.
They are two different reasons a cache throws a value away. TTL, time to live, removes a value after a fixed time, so stale data does not live forever. LRU, least recently used, removes the value nobody has asked for in the longest time when the cache is full. Most caches use both. See LRU cache.
Read-through is about reads: on a miss, the cache loads the value from the database. Write-through is about writes: every write goes to the cache and the database at the same time, so the cache is never behind. They are often used together.
Checked against these on .
Cache-Aside
A caching pattern where the application checks the cache first; on a miss, it fetches from the database and populates the cache. Also called lazy loading.
Write-Through Cache
A caching pattern where every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
Cache Stampede
When many requests hit the database simultaneously because a popular cache entry expired. Solved with locking, probabilistic early expiration, or request coalescing.
TTL
Time To Live: how long a cached entry, DNS record, or packet is valid before it expires and must be refreshed or discarded.
LRU Cache
A cache that, when full, throws away the item nobody has used for the longest time. It keeps recently used data on the bet that it will be used again soon.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
This page explains the idea. The "Read-Through Cache" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 769 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Read-Through Cache lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.