Pub/sub

Redis pub/sub is a fire-and-forget fan-out channel: publishers send messages to channel names; subscribers online at that moment receive them. There is no persistence, acknowledgment, or replay — missed messages are gone.

					# subscriber terminal
SUBSCRIBE live:scores
# publisher terminal
PUBLISH live:scores '{"match":9,"score":"2-1"}'

# pattern subscribe
PSUBSCRIBE notifications:*
				

| Fit pub/sub | Do not use pub/sub | |-------------|-------------------| | Live UI updates | Payment or order workflows | | Ephemeral notifications | Audit or event sourcing | | Low-latency broadcast | Consumers that may be offline | | Cache invalidation hints | Cross-region durability needs |

Pub/sub shares the Redis connection in classic mode — production clients often use a dedicated subscriber connection. For durable workloads use Streams, an external broker, or outbox pattern from the database.

On interviews: state delivery guarantees explicitly — at-most-once, no backlog for slow consumers.

Common pitfalls: using pub/sub as a job queue; no reconnect/backoff story; huge payloads on hot channels; coupling critical logic to message delivery without idempotency.

The trade-off is minimal latency broadcast versus zero durability — pub/sub is for hints and live fan-out, not for work that must survive restarts or slow consumers.

Checklist:

• Confirm lost messages are acceptable.
• Use separate connection for subscribers.
• Keep payloads small and schema-stable.
• Name durable alternative if requirements grow.