01A publisher sends to a channel with zero subscribers. What persists in Redis afterward?introScenarioA service publishes a status update to a channel at a moment when nobody happens to be subscribed.AThe message is stored in the channel's backlog until the first subscriber arrives to collect it.BThe channel is created as a key in the keyspace, holding a zero-subscriber marker until someone joins.CThe message is appended to the AOF, so a subscriber that connects after a restart can still replay it.DNothing durable persists; Redis only returns a receiver count and no message is stored for later subscribers.
02Why does `SUBSCRIBE` change the command lifecycle of that client?introScenarioA connection that was issuing normal commands sends SUBSCRIBE and its relationship with the server changes.ASUBSCRIBE places the client into subscription mode, where it receives pushed messages and can issue only subscription-related commands.BSUBSCRIBE starts a dedicated server thread for the client that pushes messages without involving the event loop.CSUBSCRIBE only registers interest, and the client must then poll with a fetch command to retrieve queued messages, trading delivery latency for a much simpler client implementation.DSUBSCRIBE pins the client to the channel's node and otherwise leaves its command dispatch unchanged.
03Compare Pub/Sub and streams for a chat notification that must survive reconnect.appliedScenarioA chat application must show notifications even to users whose connections dropped for a minute.APub/Sub with pattern subscriptions survives reconnect, because patterns are stored on the server side.BEither works, as long as the client reconnects within the retention window that Pub/Sub keeps per channel.CUse streams when the notification must survive reconnect; Pub/Sub is live fanout and drops messages while the client is offline.DPub/Sub is the right choice, with durability added by having each client persist every message it receives to local storage as soon as it arrives over the subscription.
04A pattern subscriber and channel subscriber both match one publish. What must the server count and deliver?appliedScenarioOne client subscribed to `news.*` as a pattern and another subscribed to the channel `news.tech`; a message is published to `news.tech`.AThe server deduplicates so each connected client receives at most one copy of any logical message.BThe server must count and deliver both the channel message and the pattern message according to matching subscription paths.CPattern matches are delivered on the next timer tick, so only the channel subscriber counts toward the reply, keeping publish latency predictable under load.DThe publish reply counts channel subscribers only, while pattern deliveries happen without being reported.
05Why are output buffer limits especially important for Pub/Sub clients?advancedScenarioAn operations review is deciding which client classes need strict output-buffer ceilings.APub/Sub clients can receive data without asking for it, so slow receivers can accumulate output quickly and threaten server memory.BPub/Sub replies are larger than ordinary command replies, so the same limits simply trip sooner.CLimits matter less for Pub/Sub, because subscribers control inflow by acknowledging each message they process.DThe limits exist to throttle publishers, since subscriber buffers are already bounded by their channel count.
fivenines