We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Caching Strategies
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.
In short
Cache-aside is a caching pattern where the application checks the cache first, and on a miss it reads from the database, then writes that value into the cache before returning it. The cache stays out of the read path until something actually asks for the data, which is why it is also called lazy loading.
In short
Cache-aside is a caching pattern where the application checks the cache first, and on a miss it reads from the database, then writes that value into the cache before returning it. The cache stays out of the read path until something actually asks for the data, which is why it is also called lazy loading.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Cache-Aside across a run of lessons, not one page. These 4 alone are about 92 minutes of step-by-step reading, every one with a quiz.
Cache-aside is said to degrade gracefully when the cache fails. Measured, unwrapped it answered 0.0 percent of requests, and wrapped it answered 13.0, which is exactly the database's capacity.
The cache your own code manages, the race hiding in its default pattern, and how often that race actually fires.
A self-filling cache fills itself out of users. Measured on a cold start, 13,259 of them paid the slow path, and warming the 200 most popular keys removed exactly 200.
Control access to an object by placing a surrogate in front of it, caching, security, and lazy loading in one pattern.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Cache-Aside Patternpay once,
yours for life
Cache-aside puts the application in charge of the cache. The cache (something like Redis or Memcached) and the database (something like Postgres or MySQL) do not talk to each other. The application code sits between them and decides what to read and write where.
The contract is simple. To read a value, look in the cache. If it is there (a cache hit), return it. If it is not (a cache miss), read from the database, copy the result into the cache, and return it. Only data that someone actually requested ever ends up in the cache, so it fills lazily over time.
This is the opposite of read-through caching, where the cache library itself fetches from the database on a miss. In cache-aside the cache is a dumb key-value store and your code owns every step. That extra control is the whole point of the pattern.
On a read, the app issues a GET to the cache. A miss triggers a SELECT against the database, then a SET to write the value into the cache with a time-to-live, often 60 seconds to a few hours depending on how stale the data is allowed to get. The next read of the same key hits the cache and skips the database entirely.
Writes are where teams get into trouble. The standard cache-aside approach is to write to the database, then invalidate (delete) the cached key rather than update it. The next read repopulates the cache with fresh data. Deleting is safer than updating because two concurrent writers updating the same key can leave a stale value behind, while a delete just forces a clean reload.
Because the cache fills on demand, the first request for any key is always slow (it pays the database round trip plus the cache write). This is a cold cache. After warm-up, hit rates of 90 to 99 percent are common for read-heavy workloads, and the database only sees the small fraction of traffic that missed.
Use cache-aside when reads heavily outnumber writes and you can tolerate data being slightly stale for the length of the TTL. User profiles, product catalogs, and configuration are classic fits. It is the default caching pattern for most applications because it is resilient: if the cache goes down, the app still works by reading straight from the database, just slower.
The trade-offs are real. You write the cache logic by hand in every read path, so it is easy to forget invalidation somewhere and serve stale data. There is a race condition window where a read can repopulate the cache with an old value just after a write deleted it, so for strict correctness you sometimes need short TTLs or versioned keys. And cold caches mean a cluster restart or a flushed cache can briefly slam the database with a thundering herd of misses.
Compared to write-through (write to cache and database together) or write-behind (write to cache, flush to database later), cache-aside trades guaranteed freshness for simplicity and fault tolerance. Most teams pick it and accept eventual consistency bounded by the TTL.
Picture an e-commerce product page that gets read thousands of times per second but is edited maybe once a day. Without a cache, every page view runs a database query. With cache-aside, the first view of product 12345 misses, reads the row, and stores it in Redis under the key product:12345 with a 10 minute TTL.
Every view for the next 10 minutes is served from Redis in well under a millisecond, and the database sees zero load for that product. When an admin edits the price, the application updates the database row and deletes product:12345 from Redis. The next shopper triggers a fresh read that repopulates the cache with the new price.
This is roughly how large catalogs, session stores, and API response caches are built. The pattern scales because the database only handles misses and writes, which is a tiny slice of total traffic.
Microsoft's Azure Architecture Center describes the pattern in three steps. The application tries to read the item from the cache. On a miss, it reads the item from the data store. It then adds the item to the cache and returns it. When the application changes data, it writes to the data store and then removes the cached item, so the next read loads the new value.
The order of that write matters. Update the database first, then delete the cache key. If you delete the key first, another request can miss in the gap, read the old row, and put the stale value back into the cache, where it stays until it expires. Even with the right order, a reader can briefly see old data between the write and the next load, so the pattern does not guarantee the cache and database agree.
Microsoft lists cases where cache-aside fits badly. If the whole data set is static and fits in the cache, load it at startup and do not expire it. If most requests miss anyway, checking the cache only adds work. Sensitive data should come from the source of truth, and session state on a web farm should not depend on one server's cache. Compare it with a read-through cache and write-through, and see the URL shortener guide for cache-aside in an interview design.
Redis
The most common cache-aside store; apps GET a key, fall back to the database on a miss, then SET the value with a TTL.
Amazon DynamoDB Accelerator (DAX)
AWS documents cache-aside as the standard pattern for fronting DynamoDB with an in-memory cache for read-heavy tables.
Facebook (Memcached)
Runs a massive cache-aside layer over MySQL, reading from Memcached first and deleting keys on writes to keep data fresh at scale.
Netflix (EVCache)
Uses a Memcached-based cache-aside tier so most reads never touch the backing data store.
In cache-aside the application code reads from the database on a miss and writes the value back into the cache itself. In read-through, the cache library handles that fetch automatically, so the app only ever talks to the cache. Cache-aside gives you more control; read-through hides the logic.
Deleting is safer under concurrency. If two writers update the same key in different orders, the cache can end up holding the older value. Deleting forces the next read to repopulate from the database, which is the source of truth, avoiding that stale-write race.
It is a cache miss, so it is slow. The app pays a database read plus a cache write before returning. This is a cold cache. After that key is requested once, later reads hit the cache until the TTL expires or the key is invalidated.
No. It gives eventual consistency bounded by the TTL and your invalidation logic. A cached value can be stale until it expires or a write deletes it. If you need strict freshness, use short TTLs, explicit invalidation on every write, or a write-through pattern instead.
When a popular key expires or the cache restarts, many requests miss at once and all hit the database simultaneously. Mitigations include staggered TTLs, request coalescing (single-flight), or pre-warming hot keys.
Cache-aside is a caching pattern in which the application manages the cache itself. It checks the cache first, reads from the database on a miss, and stores the result in the cache for next time. On a write it updates the database and deletes the cached copy.
Mostly, yes. Lazy loading describes how the cache fills: an item is cached only when someone first asks for it. Cache-aside is the full pattern built on that idea, including deleting the cached copy when the data changes.
Update the database first, then delete the cache key. Deleting first leaves a gap in which another request can reload the old value and cache it again. Microsoft's cache-aside guidance calls out this order explicitly.
Skip it when the data is small and static enough to load into the cache once at startup, or when most requests would miss anyway. Avoid caching sensitive data that must always come from the source. If readers need to see a write immediately, a write-through cache is a better fit.
The industry examples in “The next question”:
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
Write-Through Cache
A caching pattern where every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
Write-Behind Cache
A caching pattern where writes go to the cache first and are asynchronously flushed to the database later. Fast writes but risks data loss on cache failure.
Cache Stampede
When many requests hit the database simultaneously because a popular cache entry expired. Solved with locking, probabilistic early expiration, or request coalescing.
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.
Cache Eviction
The process of removing entries from a cache when it's full. Common policies: LRU (least recently used), LFU (least frequently used), FIFO (first in, first out).
This page explains the idea. The "Cache-Aside Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Cache-Aside Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Cache-Aside in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
