Topics 40
Caching Patterns Cluster Sharding & Hash Slots Clustering Connection Pooling & Client Libraries Data Types Distributed Locks with Redis Expiration & Eviction Geospatial Data in Redis Hashes in Redis HyperLogLog in Redis Keyspace Notifications Leaderboards with Sorted Sets Lists in Redis Lua Scripting Persistence (RDB/AOF) Pub/Sub Rate Limiting with Redis Redis Architecture & Installation Redis as a Message Queue Redis Backup & Disaster Recovery Redis CLI & Basic Commands Redis Memory Optimization Redis Modules Overview Redis Monitoring & Observability Redis Performance Tuning & Benchmarking Redis Replication Redis Security & ACL Redis Sentinel & High Availability Redis vs Memcached Redis with Docker & Kubernetes RedisBloom (Probabilistic Data Structures) RedisJSON RedisSearch (Full Text Search) RedisTimeSeries Session Management with Redis Sets & Sorted Sets in Redis Streams Strings & Bitmaps in Redis TLS & Encryption in Redis Transactions

Caching Patterns

7 questions found

What is the cache aside pattern, and how does it work with Redis?

Beginner
In the cache aside pattern, your application first checks Redis for the data it needs, and if the data is not found, it fetches it from the primary database, stores a copy in Redis for next time, and then returns the result, keeping Redis populated only with data that has actually been requested.
value = redis.get('user:123')
if value is None:
    value = database.get_user(123)
    redis.set('user:123', value, ex=3600)
return value
Real-world example A social media app checks Redis first when loading a user profile, only querying the slower main database the first time that specific profile is requested, then serving it instantly from Redis on every later request.

Common follow-ups: What happens if the data in the database changes after it has already been cached?;How do you decide an appropriate expiration time for cached data?

Expiration & Eviction;Redis Memory Optimization

What is the write through caching pattern, and how does it differ from cache aside?

Beginner
In the write through pattern, every time data is written to the database, it is also immediately written to Redis at the same time, keeping the cache always up to date, unlike cache aside where Redis is only populated when data is actually read and requested.
def update_user(user_id, data):
    database.update_user(user_id, data)
    redis.set(f'user:{user_id}', data)
Real-world example An inventory system updates both the database and Redis together whenever stock levels change, ensuring the cached inventory count is always accurate and never stale.

Common follow-ups: What is the tradeoff of writing to both the database and cache on every update?;Does write through caching increase the time a write operation takes?

Caching Patterns;Redis Memory Optimization

What is the write behind, also called write back, caching pattern, and what risk does it introduce?

Intermediate
In the write behind pattern, data is written to Redis immediately and then asynchronously written to the database a short time later, which improves write speed since the application does not wait for the slower database, but introduces the risk of losing recently written data if Redis crashes before that data reaches the database.
redis.set(f'order:{order_id}', order_data)
-- A background worker later reads from Redis
-- and writes the same data to the database
Real-world example A high throughput analytics system writes events to Redis instantly for fast response times, using a background worker to batch and persist those events to the database a few seconds later.

Common follow-ups: How do you minimize the risk of data loss with write behind caching?;What kind of applications benefit most from this pattern despite the risk?

Persistence (RDB/AOF);Redis Performance Tuning & Benchmarking

How does the read through caching pattern work, and how is it different from cache aside from the application's perspective?

Intermediate
In read through caching, the caching layer itself is responsible for fetching data from the database when it is missing from the cache, meaning the application always just asks the cache for data without needing its own logic to check the database, unlike cache aside where the application explicitly handles the fallback to the database itself.
-- With read through, the cache client or library
-- automatically fetches from the database on a cache miss
-- and the application code only ever talks to the cache
Real-world example A company uses a caching library that automatically loads missing data from the database behind the scenes, simplifying their application code since it only ever needs to call the cache directly.

Common follow-ups: What libraries or tools provide built-in read through caching support for Redis?;Is read through caching harder to implement than cache aside?

Caching Patterns;Redis Modules Overview

How would you prevent a cache stampede, where many requests simultaneously try to regenerate the same expired cache entry at once?

Advanced
You can use a distributed lock so only one request regenerates the expired value while others wait briefly or serve a slightly stale version, or use a technique like probabilistic early expiration, where a small percentage of requests refresh the cache slightly before it actually expires, spreading out the regeneration load over time instead of all at once.
if redis.set(f'lock:{key}', 1, nx=True, ex=10):
    value = database.get_data()
    redis.set(key, value, ex=3600)
    redis.delete(f'lock:{key}')
else:
    -- wait briefly and retry, or serve stale data
    pass
Real-world example A popular news website prevents a cache stampede on its most viewed article by using a lock so only one request regenerates the cached article content when it expires, while other simultaneous visitors briefly see the slightly older cached version.

Common follow-ups: What is the difference between a cache stampede and normal cache misses?;How does probabilistic early expiration actually work in practice?

Distributed Locks with Redis;Redis Performance Tuning & Benchmarking

How do you implement cache invalidation correctly when the same underlying data is cached under multiple different keys?

Advanced
You need a strategy to track all the cache keys related to a specific piece of data, such as using a naming convention with tags or maintaining a set of related keys in Redis, so that when the underlying data changes, you can reliably find and delete or update every cache entry that depends on it, rather than leaving some entries stale.
redis.sadd(f'tags:product:{product_id}', 'homepage_cache', 'category_cache')
-- When the product changes, look up and invalidate
-- every cache key tagged with that product
Real-world example An e-commerce site tags every cache entry that includes a specific product's price, letting it reliably invalidate the homepage banner cache, the category page cache, and the product detail cache all together whenever that price actually changes.

Common follow-ups: What are the performance costs of maintaining these tag relationships in Redis?;Are there simpler alternatives to this tagging approach for smaller applications?

Keyspace Notifications;Redis Memory Optimization

How do you decide which caching pattern, cache aside, write through, or write behind, is right for a specific application feature?

Intermediate
You consider how tolerant the feature is to slightly stale data, how critical it is that a write is never lost, and how much read versus write traffic the feature experiences, generally choosing cache aside for read heavy data that can tolerate small delays before being cached, write through when consistency matters most, and write behind when write speed is the top priority and some risk of data loss is acceptable.
-- Read heavy, tolerant of staleness: cache aside
-- Consistency critical: write through
-- Write speed critical, some risk acceptable: write behind
Real-world example A team building a product catalog chooses cache aside since catalog data changes infrequently and can tolerate being slightly out of date, while choosing write through for account balance data where consistency is critical.

Common follow-ups: Can different caching patterns be mixed within the same application for different types of data?;How do you measure whether a chosen caching pattern is actually working well in production?

Caching Patterns;Redis Performance Tuning & Benchmarking