Which caching pattern is more common with Redis for application-level caching?

Which caching pattern is more common with Redis for application-level caching?

• A. Read-Through
• B. Write-Behind
• C. Cache-Aside
• D. In-Process Caching

Answer: (C)

This question tests how Redis is typically used for application-level caching. The common approach is Cache-Aside. In this pattern the application first checks Redis for the data. If the data is in the cache (a hit), you return it quickly. If it’s not there (a miss), the application fetches the data from the primary data store, returns it to the caller, and then stores a copy in Redis for subsequent requests. This gives tight control over when data moves into the cache and how freshness is managed, which is ideal when Redis is a fast, shared cache in front of a database. On updates, the usual practice is to write to the primary data store and then invalidate or refresh the corresponding cache entry. This keeps the cache in sync with the source of truth without introducing complexity like asynchronous writes. Other patterns are less natural in this context. Read-Through would require the cache layer itself to automatically fetch from the data store on a miss, which typically means adding a caching layer or library that sits in front of Redis; plain Redis doesn’t automatically provide this behavior. Write-Behind (asynchronous writes to the underlying store) introduces complexity and potential consistency issues, making it less common for straightforward application caching. In-Process caching lives inside a single application instance and doesn’t leverage Redis as a shared cache, so it doesn’t align with using Redis as the central application-level cache.

This question tests how Redis is typically used for application-level caching. The common approach is Cache-Aside. In this pattern the application first checks Redis for the data. If the data is in the cache (a hit), you return it quickly. If it’s not there (a miss), the application fetches the data from the primary data store, returns it to the caller, and then stores a copy in Redis for subsequent requests. This gives tight control over when data moves into the cache and how freshness is managed, which is ideal when Redis is a fast, shared cache in front of a database.

On updates, the usual practice is to write to the primary data store and then invalidate or refresh the corresponding cache entry. This keeps the cache in sync with the source of truth without introducing complexity like asynchronous writes.

Other patterns are less natural in this context. Read-Through would require the cache layer itself to automatically fetch from the data store on a miss, which typically means adding a caching layer or library that sits in front of Redis; plain Redis doesn’t automatically provide this behavior. Write-Behind (asynchronous writes to the underlying store) introduces complexity and potential consistency issues, making it less common for straightforward application caching. In-Process caching lives inside a single application instance and doesn’t leverage Redis as a shared cache, so it doesn’t align with using Redis as the central application-level cache.