Patterns Overview
Redis is not just a cache — it is a versatile data structure server that solves a class of problems that are difficult to handle well with a relational database alone. This module walks through four battle-tested patterns and explains exactly why Redis is the right tool for each.
Why Redis is Fast
Section titled “Why Redis is Fast”Redis stores all data in memory. A typical command completes in under a millisecond, orders of magnitude faster than a disk-backed database. Because Redis is single-threaded, every command executes sequentially with no locking overhead. You never have two commands interleaving their reads and writes, which makes operations atomic by default — without any extra effort from your application code.
Redis also supports TTL (Time To Live): every key can be given an expiration time. When the timer runs out, Redis silently removes the key. This built-in expiration is what makes caching and session management so clean — you do not need a background job to sweep stale data.
Patterns in This Module
Section titled “Patterns in This Module”1. Caching (cache-aside)
Section titled “1. Caching (cache-aside)”Your application checks Redis before hitting the database. On a miss it reads from the DB, stores the result in Redis with a TTL, and returns it. Subsequent reads are served directly from memory. This pattern can eliminate the majority of database load for read-heavy workloads.
2. Rate Limiting (fixed-window counter)
Section titled “2. Rate Limiting (fixed-window counter)”Each incoming request increments a counter key scoped to the caller and the current time window. If the counter exceeds the allowed limit, the request is rejected. Because Redis increments are atomic, there are no race conditions even under heavy concurrent traffic.
3. Session Store (hash per session + TTL)
Section titled “3. Session Store (hash per session + TTL)”User sessions are stored as Redis hashes — one key per session, with individual fields for each piece of session data. Setting a TTL on the session key means idle sessions expire automatically. Reads and writes are O(1) and far faster than a database row lookup.
4. Distributed Lock (SET NX PX + Lua release)
Section titled “4. Distributed Lock (SET NX PX + Lua release)”The SET key value NX PX milliseconds command sets a key only if it does not already exist and gives it a timeout. This is the foundation of a distributed lock: only one caller wins the race, and the lock is guaranteed to release even if the holder crashes.