Cache-Aside Pattern: Your App Owns the Cache
The Cache-Aside pattern makes your application the gatekeeper for the cache. On a read, your code checks the cache first; on a miss, it fetches from the database and writes to the cache. This speeds up read-heavy apps. The key footgun is stale data.
Why it exists
Applications need to serve data quickly, but primary data stores like databases can be slow. Caching provides a fast, temporary storage layer, but you need a reliable strategy to populate it and keep the data reasonably fresh. The Cache-Aside pattern is a common, straightforward way for an application to manage this process itself.
The mental model
Think of your application as a librarian. When a user asks for a book (data), you first check the 'quick access' shelf right behind the desk (the cache). If it's not there (a cache miss), you walk back to the main stacks (the database), retrieve the book, place a copy on the quick access shelf for next time, and then hand it to the user. Your application code is the librarian, actively managing what goes on the shelf.
How it works
The logic lives entirely in your application code. For a read request, the app first tries to get the data from the cache. If it's a cache hit, the data is returned immediately. If it's a cache miss, the app queries the database, stores a copy of the result in the cache for future requests, and then returns the data. For a write or update, the app writes the change directly to the database and then issues a command to invalidate (delete) the corresponding entry from the cache. The next read for that item will trigger a miss, pulling the fresh data from the database.
When to use it
Use this pattern for read-heavy workloads where data is relatively static. It's ideal when your caching technology (like Redis or Memcached) is a simple key-value store that doesn't offer built-in read-through/write-through capabilities. This pattern gives your application full control over caching behavior, policies, and expiration.
When not to use it
Avoid this pattern if you require strong consistency between your cache and your database. Because an external process can update the database without the cache knowing, there's always a window for stale reads. If your caching system already provides robust read-through/write-through features, implementing this pattern manually is redundant work.
One canonical example
A web application displays user profiles. When a profile is requested, the app first checks Redis for a key like user:123. If the key is missing, it queries the main database for user 123's data. It then saves this data to the user:123 key in Redis with a 15-minute expiration (TTL) and returns the profile. When the user updates their name, the application sends an UPDATE statement to the database and then a DEL user:123 command to Redis.
Interview question
When an application using the Cache-Aside pattern needs to update an existing piece of data, which sequence of actions does it typically perform?
- a.Update the cache with the new data, then update the database.
- b.Invalidate the cache entry, then update the database with the new data.
- c.Update the database with the new data, then invalidate the corresponding entry in the cache.Correct
- d.Update the database with the new data, then update the cache with the new data.
Why? this is the answer
The Cache-Aside pattern handles updates by writing the change to the database first, and then invalidating (deleting) the corresponding entry from the cache. This ensures the next read will fetch the fresh data from the database. Options A and B describe updating the cache directly, which is characteristic of write-through or write-back patterns, not Cache-Aside's invalidation approach.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on caching — each one lists the topics its interview covers.
See open roles