How do you cancel a Redis pattern subscription created with PSUBSCRIBE, and what happens if you instead call UNSUBSCRIBE with a channel name that the pattern matched?

## Two registries, two commands A connection's subscriptions live in two independent places: exact channel names and glob patterns (plus shard channels in a cluster, a third, separate set). The unsubscribe commands are aligned one-to-one with those registries: - `UNSUBSCRIBE [channel ...]` - exact channels only. - `PUNSUBSCRIBE [pattern ...]` - patterns only. - `SUNSUBSCRIBE [shardchannel ...]` - shard channels only (Redis 7.0+). There is no command that removes 'whatever delivers this channel to me'. Cancellation is by the literal string you registered, in the registry you registered it in. ## Literal, not semantic, matching `PUNSUBSCRIBE` compares the argument to stored patterns as raw bytes. Consequences worth stating in an interview: - `PUNSUBSCRIBE news.sports` does **not** remove the pattern `news.*`, even though the pattern matches that channel. Redis does not evaluate globs during unsubscription. - Case matters, whitespace matters, and escaping matters: `news.\*` is a different pattern string from `news.*`, and only the exact one is removed. - Unsubscribing from a pattern you never registered is not an error. Redis replies with a confirmation carrying that pattern and the unchanged count, so a 'success' reply is not evidence anything was removed. ## The no-argument forms `PUNSUBSCRIBE` with no arguments removes every pattern on the connection and emits one `punsubscribe` confirmation per removed pattern, each with the decreasing total count. If the connection had no patterns, you still get one confirmation with a null pattern element. `UNSUBSCRIBE` with no arguments behaves the same way for exact channels. Clients that read a fixed number of replies get out of sync here, since the reply count depends on server-side state - another reason to let the driver manage subscription bookkeeping. ## The count field Every subscribe and unsubscribe confirmation ends with an integer that is the connection's **total** subscription count: exact channels plus patterns together (shard channels are tracked separately). So after `SUBSCRIBE a` and `PSUBSCRIBE b.*`, a `PUNSUBSCRIBE b.*` confirmation reports `1`, not `0`, because the exact subscription to `a` remains. Reading that number as 'patterns remaining' is a frequent misreading; use `PUBSUB NUMPAT` for the server-wide pattern count instead. ## Subscriber mode and getting out of it Under RESP2, a connection holding any subscription is restricted to subscribe/unsubscribe commands plus `PING`, `RESET` and `QUIT`. It leaves that mode only when the total count returns to zero, which is why forgetting that a pattern is still registered leaves a connection apparently 'stuck' and unable to run a `GET`. `RESET` (Redis 6.2+) is the blunt instrument: it unsubscribes everything, discards any `MULTI` state and `WATCH`es, and returns the connection to a clean state. Under RESP3 (`HELLO 3`, Redis 6.0+) the restriction does not apply, since pushes are a separate protocol type, but the subscriptions themselves still need explicit cancellation. ## Lifecycle in practice - **Disconnection cancels everything.** Subscriptions are connection state; closing the socket drops all of them, and nothing is restored on reconnect. A reconnecting client must re-issue its `PSUBSCRIBE` calls, and messages published during the gap are gone for good. - **Track what you registered.** Because cancellation needs the exact string, consumers should keep the pattern strings they used rather than reconstructing them, especially when patterns are built from configuration or interpolation. - **Prefer the no-argument form when tearing down.** For a consumer shutting down a whole feed, `PUNSUBSCRIBE` with no arguments avoids string-mismatch bugs entirely. ## What an interviewer is listening for That pattern and exact subscriptions are separate registries with separate commands, that matching on unsubscribe is literal rather than glob-evaluated, that the confirmation count is the connection total, and that unsubscribing a pattern you never had still returns success.