Redis Caching Patterns
Visualize cache-aside, read-through, write-through, and write-behind caching patterns. See how Redis sits between your application and database to accelerate reads.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Mental Model
Caching is the practice of storing copies of data in a high-speed, in-memory layer (like Redis) so that future requests for that data can be served faster.
There are different ways to coordinate data movement between the application, the cache, and the backend database. These are known as caching patterns. Choosing the right pattern (such as Cache-Aside, Write-Through, or Write-Behind) is a critical system design decision. It determines how your application balances read performance, write latency, data durability, and cache consistency.
graph TD
Client[Client] -->|1. Request| App[App Server]
App -->|2. Try Cache| Cache[Redis Cache]
App -->|3. Fallback on Miss / Write| DB[(Database)]
Cache -.->|Write-Behind Sync| DBComponents and Why They Exist
Client
Represents the user’s browser or mobile app requesting data or initiating writes. Dispatches requests (e.g. GET /user) and processes responses. In the demo, note the latency differences on the client response—fast sub-millisecond responses on cache hits vs. slower responses on cache misses.
App Server
Orchestrates the application logic and controls data access routing. Contains the caching policy. It decides whether to check the cache first, fallback to the database, invalidate entries, or perform asynchronous writes. In the demo, notice that follow the message paths departing from the App Server to check the cache and database during different steps.
Redis Cache
Serves as the ultra-low-latency in-memory data repository. Stores active keys, responds to lookup queries, accepts updates, and automatically evicts expired keys based on TTL. In the demo, watch the internal data list (e.g. { user: 'Alice' }) update or clear when evictions occur.
Database
Provides durable, disk-backed persistent storage of record. Handles permanent records, executes SQL transactions, and responds to queries when the cache doesn’t contain the requested data. In the demo, you can see database queries executing on cache misses or async batch updates.
Edge Cases and Misconceptions
Write-Behind (Write-Back) Data Loss
A common misconception is that Write-Behind is always the best pattern for write-heavy loads since writes return immediately. In Write-Behind, the application writes only to the in-memory cache, and a background queue asynchronously syncs it to the database later. If the Redis server crashes before the background process syncs the queue, those writes are permanently lost.
The Cache Invalidation Dilemma
“There are only two hard things in Computer Science: cache invalidation and naming things.” If you update the database directly (Write-Around) but forget to delete the cache entry, the cache will continue to serve stale data until the TTL expires. Even with Write-Through, if database updates fail after cache writes succeed, the cache and database will diverge, causing consistency errors.
Write-Through Write Latency
While Write-Through ensures the cache is never stale, it does so at the cost of write performance. Every write transaction must write to both Redis and the persistent database before acknowledging success. This makes write-through unsuitable for write-heavy services, where Write-Around or Write-Behind are preferred.
Common Questions
What is the difference between Cache-Aside and Read-Through caching?
- In **Cache-Aside** (Lazy Loading), the application code is responsible for coordinating the cache and database. The app checks the cache; on a miss, the app queries the DB, updates the cache, and returns. - In **Read-Through**, the application treats the cache as the sole data provider. If a miss occurs, the cache library itself fetches the data from the database and updates itself transparently to the application.
How does Write-Behind caching trade consistency for performance?
Write-Behind provides the lowest write latency because writes are acknowledged as soon as they are written to the fast in-memory cache. However, it sacrifices strong consistency. The database is updated asynchronously, meaning for a short window, the database holds stale data, and a crash during this window results in permanent data loss.
What is a cache stampede and how do locks prevent it?
A cache stampede occurs when a highly popular key expires, and thousands of concurrent client threads experience a cache miss at the same time. They all query the database simultaneously, which can crash the DB. To prevent this, the first thread to experience a miss acquires a distributed lock (mutex). Other threads wait or retry, while only the lock-holder queries the database and updates the cache.
When should you choose Write-Through over Write-Around?
Choose **Write-Through** when data is updated frequently and read immediately after (e.g., user profiles or settings), ensuring the read path is always a fast cache hit. Choose **Write-Around** (updating the DB directly and invalidating the cache) when writes are frequent but reads are rare, preventing the cache from being cluttered with data that may never be read.