Redis medium
A client subscribes to a channel but briefly loses its network connection. What happens to the messages published during the outage?
- A Redis automatically replays all missed messages from the internal 'AOF' log once the client reconnects.
- B The messages are lost forever because standard Pub/Sub is a stateless 'Fire and Forget' broadcast.
- C Redis stores the missed messages in a Dead Letter Queue (DLQ) until the client manually pulls them.
- D The publisher's write command fails with a 'Consensus Timeout' because the subscriber was unreachable.
Answer: B. The messages are lost forever because standard Pub/Sub is a stateless 'Fire and Forget' broadcast.
Pub/Sub has no memory. If no one is listening when a message is published, it exists only for a nanosecond in the server's outgoing buffer before being discarded. For persistent history, use Redis Streams.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?