How does the cost of a Redis PUBLISH grow as the number of registered pattern subscriptions increases, and why can heavy PSUBSCRIBE usage add latency for clients doing unrelated work on the same instance?

## The two halves of a publish When `PUBLISH channel payload` runs, Redis does two distinct pieces of work. **Exact-channel delivery.** Subscriptions by literal name live in a dictionary keyed by channel. One hash lookup yields the subscriber list, then Redis appends the message to each subscriber's output buffer. Cost is O(1) lookup plus O(N) writes for N actual subscribers, which is inherent fanout you cannot avoid. **Pattern delivery.** Pattern subscriptions cannot be indexed by name, because the key is a glob rather than a value. Redis therefore keeps them in a flat list and, for every publish, iterates the entire list and runs its glob matcher on `(pattern, published channel)`. Cost is O(M) matcher invocations for M registered patterns **regardless of how many match**, plus a write per match. Documented complexity for `PUBLISH` is O(N+M). ## Why the M term hurts more than it looks Three multipliers make this term dangerous: 1. **It is paid per publish, not per subscriber.** At 50,000 publishes per second with 2,000 registered patterns, that is 100 million glob matches per second of pure overhead before any message is delivered. 2. **It is paid on the single command-execution loop.** Redis executes one command at a time, so this work directly delays every other client's commands. The symptom is not 'Pub/Sub is slow' but 'our cache reads have a bad p99', which sends people hunting in the wrong place. 3. **Pattern cost is not uniform.** A leading `*` forces the matcher to try many positions, so `*error*` is markedly more expensive per call than an anchored `logs.api.*`. Long channel names amplify this. Add duplicate delivery from overlapping patterns and the fanout write volume grows too, which shows up as output-buffer memory and network bytes rather than CPU. ## Diagnosing it - `PUBSUB NUMPAT` gives the number of registered patterns on the node - the M in the formula. A surprisingly large value is the smoking gun. - `SLOWLOG GET` will contain `PUBLISH` entries once M is large or patterns are expensive. - `INFO commandstats` shows `cmdstat_publish` with calls and `usec_per_call`; compare `usec_per_call` before and after pattern growth. - `LATENCY DOCTOR` / `LATENCY HISTORY command` attribute event-loop stalls to command execution generally. - `CLIENT LIST` shows subscriber connections with their `psub` counts, letting you attribute patterns to owners. ## Mitigations, roughly in order of effectiveness 1. **Use exact channels.** If consumers can enumerate what they need, N exact subscriptions beat one pattern: dictionary lookup instead of a linear scan. This is the single biggest win. 2. **Reduce M, not just per-client patterns.** M is server-wide. A hundred service instances each holding five patterns is M=500 on the node. 3. **Anchor patterns.** Prefer a literal prefix (`orders.eu.*`) over a leading wildcard (`*.eu.*`), which both narrows matches and cheapens each matcher call. 4. **Design channel names for exactness.** Hierarchical names exist so consumers can subscribe to precise leaves; if every consumer ends up needing a pattern, the naming scheme is wrong. 5. **Fan out in the application.** One consumer subscribes to a small set of channels and redistributes internally, replacing many server-side patterns with one in-process dispatch table. 6. **Watch keyspace notifications.** `notify-keyspace-events` makes Redis publish on every matching key event, so enabling `KEA` on a busy instance can generate publish rates far above your application traffic, and those channels are almost always consumed with `PSUBSCRIBE __keyevent@0__:*`. Enable only the event classes you need. 7. **Reconsider the transport.** If the requirement is durable, replayable consumption rather than a live tap, Redis Streams with explicit key-based reads avoid the publish-time pattern scan entirely, at the cost of a different consumption model. ## Cluster note Ordinary `PUBLISH` in a Redis Cluster is broadcast to the other nodes so any subscriber anywhere receives it, which means the pattern-matching cost is incurred on those nodes as well and cross-node traffic scales with publish rate. Shard channels (`SPUBLISH`/`SSUBSCRIBE`, Redis 7.0+) confine a publish to one shard and deliberately have **no** pattern form, which is itself a hint about the cost of pattern matching at scale. ## What an interviewer is listening for The O(N+M) shape with M as the server-wide pattern count paid per publish, the connection to Redis's single execution loop and therefore to unrelated clients' latency, concrete diagnostics (`PUBSUB NUMPAT`, `commandstats`, `SLOWLOG`), and mitigation by preferring exact channels and shrinking or anchoring patterns.