SDI.
All Protocols
Streaming

WebSocket

WebSocket is a full-duplex communication protocol that enables persistent, bidirectional message exchange between client and server over a single TCP connection.

WebSocket starts with an HTTP upgrade handshake, then switches to a persistent, full-duplex TCP connection. Once established, both client and server can send messages independently at any time — no request-response cycle needed. Messages are framed (not streamed bytes), so you get discrete messages without manual parsing. It has native browser support via the WebSocket API. The protocol adds minimal overhead (2-14 bytes per frame vs hundreds of bytes for HTTP headers). It's the backbone of real-time apps: chat, gaming, live dashboards, collaborative editing.

Strengths

  • True full-duplex bidirectional communication with minimal per-message overhead (2-14 bytes)
  • Native browser support via the standard WebSocket API — no plugins or polyfills needed
  • Real-time message delivery with sub-millisecond latency after connection establishment
  • Supports both text and binary data, enabling efficient transfer of any payload type
  • Single persistent connection eliminates repeated handshake overhead of HTTP polling
  • Wide server-side ecosystem with mature libraries in every major language

Weaknesses

  • Stateful connections make horizontal scaling significantly harder — requires pub/sub infrastructure
  • No built-in reconnection, message ordering, or delivery guarantees — all must be implemented by the application
  • No schema enforcement or message structure — the application must define its own protocol
  • Authentication during handshake is awkward — browser API doesn't support custom headers
  • Some corporate proxies and firewalls block WebSocket upgrade requests
  • Connection-per-client model consumes server memory and file descriptors, requiring capacity planning

Technical Profile

Latency Profile

After the initial HTTP upgrade handshake (one round-trip), WebSocket messages are delivered with sub-millisecond overhead — essentially TCP latency plus minimal framing. This is dramatically lower than HTTP polling (which adds request overhead every poll interval) or long polling (which has reconnection delay). For a chat application, typical message delivery latency is 10-50ms across the internet, dominated by network RTT rather than protocol overhead.

Payload Format

Any

Browser Support

Yes

Streaming Support

Bidirectional

Schema Enforcement

None

Ideal Use Cases

  • Real-time chat and messaging applications requiring bidirectional communication
  • Collaborative editing tools (documents, design, code) with multi-user synchronization
  • Live dashboards and monitoring with sub-second data updates
  • Multiplayer online games requiring low-latency state synchronization
  • Financial trading platforms with real-time market data and order execution

Real-World Examples

Slack

Uses WebSocket for real-time message delivery, presence indicators, and typing notifications across channels, with a REST API fallback for reliability

Figma

Real-time collaborative design tool using WebSocket for multi-user cursor tracking, live editing synchronization, and operational transformation

Binance

Cryptocurrency exchange using WebSocket streams for real-time market data (order books, trade feeds, ticker updates) with millions of concurrent connections

Discord

Uses WebSocket (Gateway API) for real-time voice, video, and text chat with presence tracking across millions of concurrent users

Trello

Real-time board updates using WebSocket to synchronize card movements, edits, and comments across all connected users viewing the same board

Likely Follow-Up Questions

  • How would you scale a WebSocket-based chat system to handle 10 million concurrent connections?
  • What happens when a WebSocket client disconnects and reconnects — how do you handle missed messages?
  • Compare WebSocket vs Server-Sent Events for a live dashboard that only pushes updates from server to client.
  • How would you implement authentication for WebSocket connections given that the browser API doesn't support custom headers?
  • How would you handle backpressure when a slow client can't keep up with the server's message rate?

Source: editorial — Synthesized from RFC 6455, MDN WebSocket documentation, and production architecture case studies from Slack, Discord, Figma, and Binance engineering teams.

Command Palette

Search for a command to run...