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
The client represents the user’s browser or mobile app requesting data or initiating writes. It dispatches requests (such as GET /user) to the application tier and experiences sub-millisecond latency on cache hits compared to much slower roundtrips on cache misses.
App Server
The app server orchestrates application logic and enforces the active data access pattern. Depending on the selected caching policy, message paths from the App Server check the cache first, fall back to the database on a miss, invalidate stale keys, or queue asynchronous writes.
Redis Cache
The Redis cache serves as the low-latency in-memory data store sitting alongside the database. It holds active keys (such as { user: 'Alice' }) in RAM, responds to lookup queries, accepts writes, and clears expired keys when TTL evictions occur.
Database
The database provides durable, disk-backed persistent storage as the system of record. It stores permanent records, executes SQL transactions, and handles fallback read queries on cache misses as well as asynchronous write-behind flushes.
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.