Real-Time Communication: WebSockets, Polling & Streaming

Concept Overview

Real-Time Communication refers to the ability of a system to push data from a server to a client immediately as it becomes available, without the client explicitly having to request it repeatedly. In modern distributed systems, this is a fundamental requirement for interactive user experiences.

Traditionally, the web was built on a request-response model (HTTP). The client asks for data, and the server responds. However, this model breaks down when data changes frequently on the server side, leading to the evolution of techniques like Polling, Long Polling, Server-Sent Events (SSE), and ultimately, WebSockets.

Why it Matters

In large-scale systems, the decision between "pulling" data (Polling) and "pushing" data (Streaming/sockets) dictates the system's latency, server load, and scalability. Making the wrong choice can lead to battery drain on mobile devices, network congestion, or stale data being displayed to users.

---

Where the Concept Fits in a System

Real-time protocols sit at the Application Layer, managing how clients (browsers, mobile apps) maintain a persistent or semi-persistent link to the backend infrastructure.

---

Real-World Use Cases

Industry applications of real-time communication go far beyond simple chat apps.

1. Collaborative Editing (e.g., Figma, Google Docs)

• Scenario: Multiple users editing a document simultaneously.
• Requirement: Ultra-low latency for cursor movements and text updates. Conflict resolution (OT/CRDTs) is needed.
• Protocol: WebSockets are essential here for full-duplex communication (sending edits and receiving updates simultaneously).

2. Live Sports Ticker / Stock Ticker

• Scenario: Broadcasting live scores or stock prices to millions of viewers.
• Requirement: High throughput broadcast, low latency. Data flows primarily one way (Server -> Client).
• Protocol: Server-Sent Events (SSE) or WebSockets. SSE is often preferred for unidirectional data as it's simpler and works over standard HTTP.

3. Ride-Sharing Location Tracking (e.g., Uber, Lyft)

• Scenario: User watching the driver's car move on a map.
• Requirement: Continuous stream of geolocation updates.
• Protocol: WebSockets (or MQTT for IoT devices) to handle the frequent, lightweight location packets efficiently without the overhead of establishing new HTTP connections.

---

Read vs Write Considerations

When designing real-time systems, the flow of data impacts your architecture significantly.

---

---

Design Strategies

How do we move data? Let's look at the evolution of strategies.

1. Short Polling (The "Are we there yet?" Approach)

The client sends a request every $X$ seconds to check for data.

• Pros: Simplest to implement. Standard HTTP.
• Cons: Wastes resources/bandwidth if no data exists. High latency (average latency = interval / 2). "Chatty".

2. Long Polling (Hanging GET)

The client requests data; the server holds the connection open until data is available or a timeout occurs.

• Pros: Better latency than short polling. Less "chatty".
• Cons: Server consumes a thread/resource while waiting. Reconnecting overhead still exists.

3. WebSockets (True Real-Time)

A single TCP connection is established and upgraded. Both parties send data at will.

• Pros: Lowest latency, lowest overhead (header is sent only once), Full Duplex.
• Cons: Complex to implement (stateful implementation). Requires specialized load balancing.

Protocol Comparison

---

Failure & Scale Considerations

Scaling real-time systems introduces unique challenges:

1. The C10K Problem and Beyond

Handling 10,000 (or 10 million) concurrent connections requires non-blocking I/O architectures (like Node.js, Go routines, or Java Netty). Traditional thread-per-request models (like Apache/PHP) fail here because they run out of OS threads.

2. Connection State & Load Balancing

Because WebSocket connections are persistent, you cannot simply Round-Robin requests. If Client A connects to Server 1, Server 1 holds that state. If Server 1 dies, the connection is lost.

• Solution: Clients must implement reconnection logic with exponential backoff.

3. Heartbeats

How do you know if a connection is dead? A TCP connection might stay "open" even if the wire is cut.

• Strategy: Implement application-level Heartbeats (Ping/Pong frames). If the server doesn't hear a Pong within $N$ seconds, it closes the resource to prevent memory leaks.

---