Important limitation: The notification fires after the key is deleted. There is a brief window where the key does not exist in Redis. Re-population via the notification handler closes this window, but it is not instantaneous. If a request arrives during this window, it sees a miss.

---

Practical Pattern: Session Expiry Hook

Notify your application when a user's session token expires:

---

Practical Pattern: Audit Log for Sensitive Keys

Log all modifications to a sensitive key namespace:

---

The Critical Limitation: At-Most-Once Delivery

This is the most important thing to understand about keyspace notifications, and it is often buried in documentation:

Keyspace notifications use Pub/Sub internally. Pub/Sub has no delivery guarantees.

If your subscriber is disconnected when an event fires — Redis restart, network blip, subscriber process crash — the notification is permanently lost. There is no replay. The key expired, and your application never found out.

Consequences:

• Cache re-population handler misses expiry → cache is not re-populated → next request is a miss (relatively benign)
• Session expiry handler misses expiry → cleanup logic does not run → sessions left in database (moderate)
• Audit logger misses events → incomplete audit trail (severe for compliance)

Keyspace notifications are not suitable for:

• Authoritative event processing where every event must be handled
• Audit logs that must be complete
• Any workflow where missing an event causes permanent data inconsistency

For reliable event delivery, use Streams. Configure your application to write to a Stream on every relevant Redis write, and process the Stream with consumer groups and ACK semantics.

---

Performance Impact

Every Redis write command that matches the configured notification flags generates an internal event and publishes it to the relevant Pub/Sub channels. This adds CPU overhead to the write path.

Rough overhead:

• "Ex" (expiry only): minimal — only triggered on TTL-based key deletion
• "KEA" (all events): 5–15% additional CPU per write operation for a write-heavy instance

Do not enable "KEA" on a write-heavy production instance without benchmarking.

For most use cases:

• "Ex" for expiry hooks (lowest overhead)
• "K$" for String write monitoring
• "Kxg" for expiry + generic commands (DEL, EXPIRE) monitoring

---

Key Miss Events (m flag)

notify-keyspace-events "KEm"

Key miss events fire whenever a command accesses a key that does not exist. This can generate enormous event volume on a cache with a non-trivial miss rate. Do not enable key miss events unless you have a specific reason and have measured the overhead.

---

Keyspace Notifications vs Streams for Event-Driven Design

The pattern for reliable event-driven Redis:

1. Your application writes data to Redis
2. Your application also writes an event to a Redis Stream
3. Consumers process the Stream with consumer groups and ACK

Keyspace notifications are a convenience layer — they are fine for non-critical triggers where occasional missed events are acceptable.

---

Summary

• Enable with CONFIG SET notify-keyspace-events "flags" — disabled by default due to CPU overhead
• Two channel types: Keyspace (__keyspace@{db}__:{key} → event name) and Keyevent (__keyevent@{db}__:{event} → key name)
• For expiry hooks: subscribe to __keyevent@0__:expired with flag "Ex"
• Critical limitation: at-most-once delivery — notifications are lost if the subscriber is disconnected
• Not suitable for authoritative event processing, audit logs, or any workflow requiring guaranteed delivery
• Overhead scales with event flag breadth — "Ex" is minimal; "KEA" is significant on write-heavy instances
• For reliable event-driven architectures: write to Redis Streams instead and use consumer groups

Next: P-9 — Session Management Patterns — storing sessions as Hashes vs JSON strings, sliding expiry, multi-device sessions, and the consistency trade-offs when reading from replicas.

---