WebSocket ingest
WebSocket ingest is the delivery of recording events to the backend over a persistent socket connection instead of batched HTTP requests. It trades connection management complexity for low latency and ordered streaming, and it is the transport that makes live replay practical.
How it works
The recorder's emit callback writes events to an open WebSocket, usually with lightweight client-side buffering for reconnects, and the ingest service appends them to the session's stream in arrival order. Against HTTP batching (POST every few seconds, simple, cache-friendly, resilient), sockets win when event-to-visibility latency matters: live mode viewing, real-time alerting on frustration signals, and agent supervision all want events within a second, not thirty. Production concerns concentrate on the unhappy paths: reconnection with resume, backpressure when a client outpaces ingest, and load balancer configuration for long-lived connections. Many stacks run both transports, HTTP for routine recording and sockets for sessions someone is watching live.
Where you encounter it
Live support and co-browsing setups, rrweb Cloud's streaming ingest, and self-hosted architecture decisions in the self-hosted session replay guide.