In the RESP protocol, most frames a client reads are replies to commands it sent. Explain what an out-of-band push frame is, why the older protocol version could not express one, and what capabilities it unlocked.

## The request/response assumption RESP is fundamentally a request/response protocol over a single TCP connection with **ordered replies**: the Nth reply corresponds to the Nth request. That property is what makes pipelining trivial — write ten requests, read ten replies, match by position. A client reader is therefore usually a simple loop: read one frame, hand it to the caller at the head of the pending queue. That model has no room for a frame the client did not ask for. ## How RESP2 coped, badly Pub/Sub needs exactly such frames: after `SUBSCRIBE news`, the server sends a frame whenever anyone publishes, at an arbitrary time. In RESP2 that frame is an ordinary array: ``` *3\r\n$7\r\nmessage\r\n$4\r\nnews\r\n$5\r\nhello\r\n ``` Shape-wise this is indistinguishable from, say, an `LRANGE` reply of three strings. A client reading frames in order cannot know whether the array it just read is the answer to its pending `GET` or a published message. Redis solved this by **constraining the connection**: once a RESP2 connection enters subscribe mode, it may only run subscription commands plus `PING`, `QUIT`, `RESET` (and `SUBSCRIBE`-family variants). Any other command returns an error. The practical cost: every application that both reads/writes keys and subscribes needs **two connections** and two pools, and Pub/Sub cannot be layered onto a general-purpose client without extra machinery. It also means the server has no general way to notify a client about anything at all. ## What RESP3's push type changes RESP3 (Redis 6.0+, opted into per connection with `HELLO 3`) introduces the `>` prefix: ``` >4\r\n$7\r\nmessage\r\n$4\r\nnews\r\n$5\r\nhello\r\n... ``` Structurally it is an array of N elements; semantically the `>` says **this is not a reply**. That single bit of type information is enough to restore the client's ability to demultiplex: - the reader loop reads a frame; - if it is `>`, dispatch it to a registered listener (by the first element, which names the kind: `message`, `pmessage`, `subscribe`, `unsubscribe`, `invalidate`, ...); - otherwise, complete the oldest outstanding request. The pending-request queue is untouched by push frames, so ordering guarantees for replies still hold. ## Capabilities it unlocked **1. Pub/Sub on a shared connection.** In RESP3 a subscribed connection is no longer restricted; a client can `SUBSCRIBE` and still run `GET`/`SET` on the same socket. This simplifies pooling, halves connection counts for subscriber-heavy apps, and lets libraries expose subscription as an ordinary API rather than a special connection mode. **2. Client-side caching (`CLIENT TRACKING`).** This is the flagship use. With tracking enabled, the server remembers which keys a connection has read and, when such a key changes, **pushes** an `invalidate` message listing the keys. The client keeps a local in-process cache and drops entries on invalidation, eliminating round trips entirely for hot keys. Variants exist — default mode tracks read keys per connection; `BCAST` mode pushes invalidations for key prefixes without per-key bookkeeping; `OPTIN`/`OPTOUT` control which reads are tracked; and `REDIRECT` sends invalidation pushes to a *different* connection id, which is how RESP2 clients can participate at all (they keep a second connection in subscribe mode receiving `__redis__:invalidate`). The push type is what makes the primary path clean. **3. Server-initiated notifications generally.** Keyspace notifications and similar event streams can be delivered without hijacking the connection, and the protocol now has a place for future server-to-client signalling. ## Implementation consequences for client authors - **Any frame may be a push.** The reader must check the type byte on every frame, not only when it believes a subscription is active — an invalidation can arrive between two replies in a pipeline. - **Thread-safety.** Dispatching a push to user code from the reader thread means user callbacks must not block the reader; libraries usually hand off to a queue or executor. - **Ordering.** A push is delivered in stream order relative to replies, but carries no guarantee about *when* relative to the key operation that caused it in another client — an invalidation is an eventual signal, and there is a genuine race window in which a client may serve a stale locally-cached value. Designs that need correctness under that race use short local TTLs alongside invalidation. - **Backpressure.** A client that ignores pushes still has them accumulate in its socket buffer, and the server accounts them against the client output buffer limits; a slow reader can be disconnected. ## The short version for an interview RESP2's frames were all replies, so unsolicited messages had to masquerade as replies and the connection had to be locked into subscribe mode. RESP3's `>` push type names unsolicited messages explicitly, which restores multiplexing and, more importantly, gives the server a channel to tell clients things — with invalidation-driven client-side caching being the capability that channel was really built for.