What are Redis keyspace notifications?

Question

IT Interview Practice · Accepted Answer

**Keyspace notifications** let clients subscribe (via Pub/Sub) to events about changes to keys — such as a key being set, deleted, or **expired**. They enable reacting to data changes in Redis, with the expiration event being a particularly common, useful trigger. ## Enabling and subscribing ```bash # keyspace notifications are OFF by default — enable the event classes you want CONFIG SET notify-keyspace-events KEA # K=keyspace, E=keyevent, A=all event types # subscribe to events: e.g. all expirations across the database PSUBSCRIBE "__keyevent@0__:expired" # fires when ANY key expires (with the key name) PSUBSCRIBE "__keyspace@0__:mykey" # all events on a specific key ``` You enable notifications (`notify-keyspace-events`, choosing which events) and subscribe to special channels: `__keyevent@__:` (events of a type, e.g. `expired`, with the affected key) or `__keyspace@__:` (events on a specific key). ## The expiration event: a common pattern ```text The "expired" event is widely used as a TIMER/SCHEDULER: → set a key with a TTL; when it expires, you get notified → trigger an action → e.g. "order:123:hold" expires in 15 min → notification → release the held inventory → delayed jobs, session-expiry handling, scheduled actions without a separate scheduler ``` ## Important caveats ```text ⚠️ Built on PUB/SUB → fire-and-forget: if no subscriber is connected when the event fires, it's MISSED (not reliable/persistent). Don't rely on it for critical events. ⚠️ "expired" fires when the key is actually REMOVED (lazy/active expiration), which can LAG behind the exact TTL time → not precise timing. ⚠️ Has overhead at high volume; for reliable event handling, use STREAMS instead. ``` ## Why it matters Understanding keyspace notifications is useful knowledge for **reacting to data changes in Redis**, a capability that enables certain event-driven patterns — though understanding its limitations is equally important. The feature lets clients **subscribe to events about key changes** (sets, deletes, and especially **expirations**) via Pub/Sub, enabling Redis to notify the application when data changes. The **expiration event in particular** powers a common, elegant pattern: using a key's TTL as a **timer/scheduler** — set a key to expire after some delay, and the expiration notification triggers an action (releasing held inventory after a hold period, handling session expiry, running delayed jobs), providing scheduled-action behavior without a separate scheduling system. Understanding how to enable notifications (`notify-keyspace-events`) and subscribe to the special keyevent/keyspace channels is the practical mechanism. Critically, understanding the **caveats** is essential to use this correctly: because it's built on **Pub/Sub, it's fire-and-forget** (events with no connected subscriber are permanently missed — so it's unreliable for critical events), the **expired event lags** the exact TTL (firing when the key is actually removed by lazy/active expiration, so timing isn't precise), and it has overhead at high volume — meaning for reliable event handling, Streams or another mechanism is better. This awareness prevents over-relying on notifications for guaranteed delivery. Since reacting to Redis data changes (especially expirations as timers) is a useful pattern for delayed actions and scheduling, and since keyspace notifications provide it but with important reliability and timing limitations (inheriting Pub/Sub's fire-and-forget nature), understanding keyspace notifications — what they are, the expiration-as-timer pattern, and especially the caveats — is valuable, practically-relevant knowledge for using this feature appropriately while knowing when its limitations require a more reliable approach.

Enabling and subscribing

The expiration event: a common pattern

Important caveats

Why it matters

Related questions