Push
RESP3prefix: > · client type: callback / event / async handler
Push data is the most architecturally significant RESP3 addition. A > frame is sent by the server at any time, interleaved with regular replies, without being a response to a command. The first element identifies the push type (pubsub, monitor, keyspace, etc.). Clients invoke registered callbacks. RESP3 push allows pub/sub subscriptions on the same connection used for regular commands.
Details
Push data has the format >N\r\n followed by N elements, where the first element is always a simple or bulk string naming the push type.
In RESP2, pub/sub required a dedicated connection because subscribing changed the connection mode permanently. Regular commands could not be sent on a subscribed connection. RESP3 solves this: push messages arrive as > frames interleaved with command replies, without blocking or changing connection state.
Push types in Redis: pubsub – Pub/Sub message or subscription confirmation keyspace – keyspace notification (if enabled) monitor – MONITOR output (if monitoring mode) invalidate – client-side cache invalidation (Redis 7.4+ with CLIENT TRACKING)
Push and command replies interleaving: Client sends GET mykey. Before the GET reply arrives, the server may push: >4\r\n+pubsub\r\n+message\r\n+channel1\r\n+hello\r\n The client processes the push (invokes pubsub callback), then reads the GET reply. Command reply ordering is preserved – the next non-push reply is the GET reply.
Client implementation: asynchronous clients use event loops and invoke callbacks. Synchronous clients must check each received frame and dispatch push frames to handlers before continuing to read command replies.
Wire encoding
>4\r\n+pubsub\r\n+message\r\n+mychannel\r\n+hello world\r\n >3\r\n+pubsub\r\n+subscribe\r\n+mychannel\r\n >3\r\n+keyspace\r\n+set\r\n$6\r\nmykey\r\n
Type information
| Prefix byte | > |
| Version | RESP3 |
| Client type | callback / event / async handler |
| Specification | RESP3 specification (GitHub) → |