A Redis subscriber consumes published messages more slowly than they are produced. What does the Redis server eventually do about it, which configuration governs that, and what does the application see?

## Where the backlog lives Redis does not apply backpressure to a publisher. `PUBLISH` writes the message into each subscriber's client output buffer and returns immediately; the socket is drained later by the event loop. If a subscriber reads slower than the publish rate, the difference accumulates in that buffer, in the server's memory, on the publisher's behalf. The producer is never slowed down and never told. ## The limit that ends it Because an unbounded buffer would take the whole instance down, Redis enforces per-class limits via `client-output-buffer-limit <class> <hard> <soft> <soft-seconds>`. The pub/sub class defaults to `32mb 8mb 60`: a client is closed immediately if its buffer exceeds the hard limit of 32 MB, or if it stays above the soft limit of 8 MB continuously for 60 seconds. Setting all three values to 0 disables the limit, which trades a lost subscriber for a possible out-of-memory on the server, rarely the better deal. The server logs the kill ("scheduled to be closed ASAP for overcoming of output buffer limits") and `INFO stats` counts it in `client_output_buffer_limit_disconnections`. ## What each side observes Publisher: nothing. PUBLISH returned a positive count for a client that was later killed, since the count reflects the write into the buffer, not delivery to the application. Subscriber: a connection reset. Virtually every client library reconnects and replays its SUBSCRIBE commands automatically, so unless you log reconnects, the incident is invisible and the only symptom is missing events downstream. This compounds the at-most-once nature of Pub/Sub: the messages queued in that buffer are gone, and there is no offset to resume from. Operator: memory. Output buffers are part of `used_memory`, so a large fan-out to lagging consumers inflates the instance's footprint and can trigger eviction of real keys, or make `maxmemory` behaviour look mysterious. ## Diagnosing `CLIENT LIST TYPE pubsub` shows per-client `omem` (output buffer memory) and `tot-mem`; a client with a growing `omem` is the culprit. `INFO clients` exposes `client_recent_max_output_buffer` as a cheap high-water signal to alert on, plus `pubsub_clients` (7.x) for the subscriber count. `INFO memory` will show the aggregate. Correlate a spike with your publish rate multiplied by subscriber count: fan-out is the amplifier, since one 100 KB publish to 200 subscribers is 20 MB of buffer. ## Fixes, in order Start with the consumer: the message callback must not do I/O, parse huge payloads, or take locks. Read the message, push it onto an in-process queue, return to the socket. Then shrink the payload: publish an identifier and let the consumer fetch the body, which also fits the "message as hint" rule that Pub/Sub's at-most-once semantics already forces on you. Then reduce fan-out per node, for example by splitting one busy channel into several so subscribers spread across shards. Raising `client-output-buffer-limit` is a legitimate last step when bursts are known and bounded, but it must be paired with a memory headroom calculation, because you are choosing to store more of the backlog in the server's RAM. If messages genuinely must not be dropped when a consumer lags, the honest conclusion is that Pub/Sub's fire-and-forget delivery does not match the requirement, and the design needs a stored, replayable structure instead.