Real-time Updates

- Real-time systems need two hops: server to client (WebSockets, SSE, long polling) and source to server (Pub/Sub). Start with simple polling unless you truly need sub-second latency. WebSockets need L4 load balancers for persistent connections.

30-second elevator pitch: "Real-time updates require efficient push channels. I choose based on latency needs: polling for 2-5 second updates, long polling or SSE for near real-time, WebSockets when I need bidirectional low latency. The second hop is Pub/Sub to fan out updates from the source to servers."

The Problem

Consider a collaborative document editor like Google Docs. When one user types a character, all other users viewing the document need to see that change within milliseconds. Standard HTTP follows request-response: the connection closes after each exchange. You cannot have every user polling every few milliseconds without crushing your infrastructure.

The core challenge is establishing efficient, persistent communication channels between clients and servers. Servers need to push updates to clients proactively.

9 problems that use this pattern: Ticketmaster, Uber, WhatsApp, Robinhood, Google Docs, Strava, Online Auction, FB Live Comments, and similar collaborative or live systems.

What You Will Learn

Hop 1: Client-Server Connection

- Simple polling (baseline, 2-5 sec updates)

- Long polling (server holds request until data)

- Server-Sent Events (SSE) - one-way push over HTTP

- WebSockets - full-duplex persistent connection

>

Hop 2: Source to Server

- Pub/Sub (Kafka, Redis) to fan out events

>

Deep Dives (what interviewers ask next)

- L4 vs L7 load balancers for WebSockets

- Handling reconnection and missed updates

- When polling is enough (avoid over-engineering)

The Solution: Two Hops

Real-time systems require two distinct pieces: how updates get from the server to the client, and how updates get from the source to the server.

What interviewers want to hear: "I start with the simplest approach that meets the latency requirement. Many problems do not need WebSockets - polling every 2-5 seconds is fine. If we need sub-second updates, I use long polling or SSE for one-way, WebSockets for bidirectional. The second hop is Pub/Sub to distribute updates from the source to all servers holding client connections."

Simple Polling

The client makes requests at a regular interval. Simple, stateless, works everywhere. Higher latency (up to polling interval + request time), more bandwidth with many clients.

When to use: Updates every 2-5 seconds are acceptable. Preserve interview time for parts that matter.

Long Polling

The client makes a request; the server holds it open until new data arrives. When data arrives, the server responds and the client immediately makes a new request. Near real-time over plain HTTP.

Interview tip: Long polling is often the easiest real-time solution. No special infrastructure. Works with standard HTTP and L7 load balancers.

Server-Sent Events (SSE)

One-way push from server to client over HTTP. The client opens a connection; the server streams events. Automatic reconnection built-in. One-way only.

WebSockets

Full-duplex persistent connection. Low latency, bidirectional. Requires infrastructure support: L4 load balancers (L7 can break connection stickiness), handling deployments (sever connections, clients reconnect).

Note: WebSockets need persistent TCP connections. L4 load balancers maintain them; L7 may not. Choose accordingly.

When to Use in Interviews

Use real-time patterns when the problem explicitly needs live updates: chat, live comments, collaborative editing, real-time dashboards, ride-sharing location.

When NOT to use: Most CRUD and feed systems do not need real-time. If refresh every few seconds works, say so. Do not over-engineer.

Common Deep Dives

What happens during deployment with WebSockets? Sever connections; clients reconnect. Prefer simplicity over connection persistence.

How do you handle missed updates on reconnect? Client sends last-seen timestamp or sequence; server returns deltas. Or full sync if state is small.

L4 vs L7 for WebSockets? L4 preserves TCP connection to same backend. L7 may route each request differently; use L4 for WebSockets when possible.

Summary

Two hops: client-server (polling, long polling, SSE, WebSockets) and source-server (Pub/Sub)

Start simple: polling often sufficient

WebSockets need L4 load balancers and reconnection handling

Match the protocol to actual latency requirements

{{SUBSCRIBE}}

{{BUTTON:Read More Articles|https://newsletter.systemdesignlaws.xyz}}