Pub/Sub Interview Questions

PUBLISH is fire-and-forget: if a subscriber is disconnected, the message is gone. There is no XACK and no backlog. That is the first sentence interviewers want before you mention speed.

SUBSCRIBE switches that connection into subscriber mode, so you cannot GET on it until you UNSUBSCRIBE. Use a dedicated connection. Sharing a pool connection for Pub/Sub is a classic production incident.

PSUBSCRIBE matches glob patterns such as news.*, which is convenient and easy to over-subscribe. One bad pattern can flood a client. Prefer explicit SUBSCRIBE channels when the set is known.

Redis Streams persist and replay; Pub/Sub does not. Choose Pub/Sub for live fan-out where loss is acceptable, such as presence ticks or UI invalidate. Choose STREAM when a consumer can be down for minutes and must catch up.

PUBLISH returns the subscriber count at that instant, which is a debugging hint, not a delivery guarantee. Zero means nobody was listening, not that Redis queued it. Never use the return value as an ack.

Cache invalidation over Pub/Sub is a hint to drop a local cache, not a source of truth. A missed message means stale local data until TTL. Pair with CLIENT TRACKING or a short local TTL.

Dropped-on-the-floor is the Pub/Sub contract: with zero subscribers the payload is not stored. There is no later replay when someone SUBSCRIBE. If that is unacceptable, XADD on a STREAM is the model you wanted.

SPUBLISH sharded Pub/Sub in Cluster pins a channel to a hash slot so messages are not broadcast to every node. Classic PUBLISH in Cluster is cross-node expensive. Migrate high-volume channels to sharded Pub/Sub on Redis 7+.

Output buffer limits disconnect slow Pub/Sub clients when they cannot keep up; there is no catch-up later. That is the backlog story: there is none. Tune client-output-buffer-limit pubsub or the subscriber must be faster.

Keyspace notifications such as PSUBSCRIBE __keyevent@0__:expired are Pub/Sub under the hood and inherit fire-and-forget loss. Expired events can drop under load. Do not use them as the only sweeper for billing.

Fan-out to tens of thousands of websocket clients usually needs a local process that SUBSCRIBEs once and copies to sockets. Letting every browser hold a Redis Pub/Sub connection will exhaust clients and buffers. Redis is the bus, not the websocket server.

Message loss on Sentinel or Cluster failover is expected for Pub/Sub; subscribers must resubscribe and tolerate a gap. Replicas do not replay missed publishes. If that gap is unacceptable, you needed STREAM.

Pub/Sub does not become a transaction log just because you wrap HSET and PUBLISH in MULTI/EXEC. The publish still has no backlog if listeners are down. Pipeline those two commands for latency; do not confuse that with durable notify.

Pattern subscriptions in Cluster historically required broadcasting publishes more widely than a single channel. That extra chatter shows up as internode bandwidth. Explicit channels or sharded Pub/Sub reduce it.

MONITOR is not Pub/Sub and must never be used to subscribe to all commands in production. It streams every command to one client and stalls the instance. Pub/Sub is the supported fan-out; MONITOR is a debug gun.

Ordering in Pub/Sub is per-publisher on a single node, not a global timeline across publishers. Two services PUBLISH to the same channel can interleave. If you need a total order, XADD on a STREAM.

Thousands of PSUBSCRIBE patterns increase CPU on every PUBLISH because Redis matches patterns. Explicit channel names scale better. Collapse to a small set of channels with a payload type field.

Combining a STREAM for the durable log with a Pub/Sub ping for "something new" lets workers XREAD from the last ID after a notify. The notify can drop; the STREAM cannot if persisted. That hybrid is a strong senior answer.

ACL can allow PUBLISH but deny SUBSCRIBE on a user, which is how you stop a compromised app from eavesdropping. Treat channels as sensitive if payloads have PII. TLS still matters because Pub/Sub is plaintext otherwise.

Slow consumers get disconnected when the pubsub output buffer hits client-output-buffer-limit; they never receive a replay. Instrument disconnects. If that happens often, the design should have been STREAM with XREADGROUP.