Redis & Caching Vocabulary

A TTL (Time To Live) is an expiration set on a Redis key, after which the key is automatically removed. You set it with commands like EXPIRE or by passing EX/PX options on SET, and check remaining time with TTL. TTLs are fundamental to caching: they keep cached data fresh by ensuring stale entries eventually disappear without manual cleanup. Redis expires keys both lazily (when accessed) and via a periodic sampling sweep. Choosing the right TTL balances freshness against cache hit rate and load on the backing store.

An eviction policy determines which keys Redis removes when it reaches its configured maxmemory limit and needs room for new data. Policies include LRU (least recently used), LFU (least frequently used), random, and TTL-based variants, each applicable either to all keys (allkeys-*) or only to keys with an expiry set (volatile-*). The default noeviction instead returns errors on writes once memory is full. Picking the right policy is essential when using Redis as a cache so that the least valuable data is shed first.

A cache stampede (or thundering herd) happens when a popular cache entry expires and many concurrent requests all miss simultaneously, then all try to recompute or refetch the value at once — hammering the database and potentially causing cascading failure. Mitigations include a mutex/lock so only one request rebuilds while others wait or serve stale data, probabilistic early expiration (recomputing slightly before expiry), and request coalescing. The goal is to ensure that, for any given key, the expensive recomputation happens at most once at a time.

Pipelining is a technique where a client sends many Redis commands back-to-back without waiting for each individual response, then reads all the replies together. This eliminates the per-command network round-trip latency that otherwise dominates when issuing many small operations, dramatically increasing throughput. Pipelining is purely a client-side batching optimization — it does not make the commands atomic (use MULTI/transactions or Lua for atomicity). It is especially valuable over higher-latency links where the round-trip time, not Redis itself, is the bottleneck.

Pub/sub (publish/subscribe) is a messaging paradigm in Redis where publishers send messages to named channels and any subscribers listening on those channels receive them in real time. It is fire-and-forget and decoupled — publishers do not know who, if anyone, is subscribed. Messages are not persisted: a subscriber that is offline when a message is published simply misses it. This makes classic pub/sub suited to live notifications and ephemeral fan-out. For durable, replayable streaming, Redis offers Streams instead.