Module 17 · Lesson 1 of 14Free

WebSockets, SSE and long polling compared

Level

Intermediate

Topic

Realtime systems, chat and social feeds

Reading time

19 min

Kartly marks Asha’s order as shipped. Her tracking page still says “Packing” for another 10 seconds. She refreshes twice because she thinks the shipment failed.

For this lesson’s scenario, 20,000 tracking pages are open during a festival sale. How should changes reach those pages quickly without making every browser keep asking?

Keep the request waiting instead

The simplest implementation uses polling: request the current order, wait, then request it again. Most requests return an unchanged order.

The important distinction is not “HTTP versus something fast”. It is what happens after the server sends an update.

A request ending does not necessarily mean its underlying network connection closes. Long polling can reuse an HTTP connection. Conversely, an SSE response can remain unfinished for many updates. These are different response lifecycles, not instructions to repeat a TCP handshake every time. ^{1RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTPS. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins, IETF, 2011}

Kartly already has separate order and payment services at this stage of the course. We will change only the tracking delivery path. Checkout remains an ordinary request and response.

First, follow one update through each transport.

Long polling ends with news

Suppose the page knows order version 41. A version is a server-assigned number that increases whenever that order changes.

Kartly could define this application contract:

GET /v1/orders/ord_7/changes?after=41
Accept: application/json

The tracking server authenticates Asha and checks that she owns the order. Then it:

1. Checks the current version.
2. Returns immediately if a newer version exists.
3. Otherwise registers a waiter for that order.
4. Rechecks the version after registration.
5. Waits for a change or the deadline.

The second check closes a race. Without it, an update could happen between the first check and registration. The request would then wait despite newer data being available.

When news arrives, the server returns a complete current snapshot:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"order_id":"ord_7","version":42,"status":"SHIPPED"}

The client immediately starts another request using version 42. In our contract, an empty deadline returns 204 No Content; the client repeats with its existing version.

Holding a request until data or a timeout, then issuing another request, is the long-polling mechanism. ^{1RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTPS. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins, IETF, 2011}

The server must remove the waiter when the client disconnects or the deadline expires. Otherwise, abandoned requests leave memory behind.

Long polling is useful when your infrastructure handles ordinary responses well but cannot stream them promptly. Its cost becomes clearer during frequent updates: every completed response requires another request. A snapshot check on the next request covers the gap between them.

SSE keeps one response open

With server-sent events, or SSE, the browser opens a stream:

GET /v1/orders/ord_7/events
Accept: text/event-stream

The tracking server sends response headers, then keeps writing:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-store

id: 42
event: order
data: {"order_id":"ord_7","version":42,"status":"SHIPPED"}

: keep-alive

SSE uses UTF-8 text. A blank line ends an event, and a colon-prefixed line is a comment. The event field names the event type; data carries its content. ^{2HTML StandardWHATWG, WHATWG}

Our endpoint sends complete order snapshots. JSON is Kartly’s payload choice, not a requirement of SSE.

The browser’s EventSource API handles stream parsing and reconnects after recoverable interruptions. When reconnecting the same object, it sends the remembered nonempty event ID in Last-Event-ID. That does not make the server retain or replay anything. ^{2HTML StandardWHATWG, WHATWG}

“One-way” describes this stream, not the whole application. Asha can still send a cancellation through a separate HTTPS request. Occasional user actions do not require a two-way stream.

The tracking handler must flush each completed event. A buffering intermediary can otherwise turn several timely writes into one late delivery. HTTP streaming’s buffering and timeout issues require end-to-end checks. ^{1RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTPS. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins, IETF, 2011}

This makes SSE a good fit for our tracking page, but it does not yet explain how an update finds the server holding that page.

WebSockets carry messages both ways

A WebSocket establishes a persistent two-way message channel. In the HTTP/1.1 handshake, the client requests an upgrade and the server accepts with 101 Switching Protocols. Afterward, the connection carries WebSocket frames rather than ordinary HTTP responses. Text and binary messages are supported. ^{3RFC 6455: The WebSocket ProtocolI. Fette, A. Melnikov, IETF, 2011}

For a possible support-chat feature, Kartly could define these application messages:

{"type":"send_message","client_message_id":"m_18","text":"Can I change the address?"}

{"type":"message_saved","client_message_id":"m_18","message_id":"msg_92"}

Those message types are our design, not built-in WebSocket operations. The application must define validation, permissions, acknowledgments and recovery.

Why distinguish acknowledgment from sending? A connection might fail after the server saves a message but before the acknowledgment arrives. Retrying needs a stable message identity, as covered in Idempotency: making retries safe.

WebSocket Ping and Pong frames can check whether the peer responds. They do not confirm that an application saved a chat message. ^{3RFC 6455: The WebSocket ProtocolI. Fette, A. Melnikov, IETF, 2011}

For tracking alone, two-way messaging adds an application protocol without removing our recovery work. Choose it when both directions benefit from sustained message exchange, not because “live” appears in the requirement.

Choose for the traffic you have

Our scenario requires a changed order to appear within about one second during healthy operation. Most customers only watch. Cancellation is occasional.

The decision concerns request overhead and application behavior. It does not establish a universal latency ranking. A slow database or buffered gateway can dominate any transport.

Count requests and waiting state

These are illustrative estimates for the tracking cohort, not Kartly-wide traffic measurements.

All three proposed live approaches still need state for roughly 20,000 waiting clients. Fewer requests do not mean zero connection cost.

Updates must find their subscribers

A transport delivers bytes from a tracking server to a browser. It does not tell that server about a change committed elsewhere.

Here is the smallest shared delivery path we need for Kartly’s existing services:

The order service owns each snapshot. Its database row includes id, customer_id, version and status. The primary key serves reads by order ID.

For this design, the service updates the status and increments the version in the same transaction. Concurrent changes to one order therefore receive distinct increasing versions. Business rules decide which transitions are allowed; the transport does not.

The write path is:

1. The order service validates the requested transition.
2. It commits the updated snapshot and version.
3. It publishes the order ID as a wake-up signal.
4. The tracking service reads the latest committed snapshot.
5. It sends that snapshot to local subscribers.

The read path starts differently:

1. The browser opens the stream through the gateway.
2. The tracking service verifies ownership.
3. It registers for wake-ups before reading the current snapshot.
4. It sends the snapshot, then forwards newer versions.
5. It removes the subscription when the stream closes.

Registering before reading prevents a gap between the initial snapshot and live delivery. Duplicate notifications are harmless because versions identify newer snapshots.

Publishing after commit avoids announcing uncommitted state. However, a crash between commit and publish still loses the signal. We need recovery independent of that signal.

Reconnection is not state recovery

Imagine Asha received version 41. Her network drops. Kartly commits version 42, but she reconnects only afterward.

Opening another connection does not reconstruct the missing information. The application must choose what to recover.

Our SSE endpoint therefore sends the latest snapshot on every connection, even when Last-Event-ID is present. Its id is the order version, not a promise of replay.

For this scenario, the tracking service also checks subscribed orders every 30 seconds. It batches these reads by order ID and sends only newer versions. This repairs missed broker signals even when the browser connection stays open.

That repair interval permits delayed freshness during failures. It is not the healthy-operation target.

Keep old snapshots from moving backward

A live update and a recovery read can finish in different orders. Suppose version 43 arrives before a slower read returns version 42.

The browser owns this small merge function. Both examples assume the payload has already passed runtime validation.

from dataclasses import dataclass

@dataclass(frozen=True)
class Snapshot:
    order_id: str
    version: int
    status: str

def merge_snapshot(
    current: Snapshot | None,
    incoming: Snapshot,
) -> Snapshot:
    if current is None:
        return incoming
    if incoming.order_id != current.order_id:
        raise ValueError("Different order")
    if incoming.version > current.version:
        return incoming
    return current

current = Snapshot("ord_7", 43, "DELIVERED")
late = Snapshot("ord_7", 42, "SHIPPED")
print(merge_snapshot(current, late).status)

type Snapshot = Readonly<{
  order_id: string;
  version: number;
  status: string;
}>;

function mergeSnapshot(
  current: Snapshot | null,
  incoming: Snapshot,
): Snapshot {
  if (current === null) return incoming;
  if (incoming.order_id !== current.order_id) {
    throw new Error("Different order");
  }
  return incoming.version > current.version ? incoming : current;
}

const current: Snapshot = {
  order_id: "ord_7", version: 43, status: "DELIVERED",
};
const late: Snapshot = {
  order_id: "ord_7", version: 42, status: "SHIPPED",
};
console.log(mergeSnapshot(current, late).status);

Both print DELIVERED. Equal versions are ignored too. This relies on one important invariant: equal versions describe the same immutable snapshot for that order.

The function does not recover missing chat messages. It works because each tracking payload replaces the entire displayed state.

Common mistakes

• Choosing WebSockets to guarantee delivery. A persistent channel does not replace stored state, message identities or recovery rules.
• Holding a database transaction while waiting. Read and release database resources. Wait in the connection-handling layer.
• Treating an open stream as fresh data. A missed broker signal can leave a healthy connection showing old state. Measure freshness and reconcile.
• Changing transport to fix buffering. First locate the delay. A different protocol may introduce work without fixing the failing intermediary.

These mistakes share a cause: asking the transport to solve a problem owned by another layer.

Keep waiting clients inexpensive

Use the waiting model from Server concurrency. A parked stream should not reserve an expensive worker or a database connection.

Set a byte limit on each client’s output buffer. For our complete snapshots, an unsent older snapshot can be replaced by the newest one. If writes remain blocked, close the stream and let recovery reload current state. Backpressure explains the broader mechanism.

As an illustrative memory budget, allowing 64 KiB of buffered output per stream permits about 1.22 GiB across this cohort. That excludes connection objects, encryption and operating-system buffers. A small per-client allowance becomes significant when multiplied.

Choose a heartbeat interval below the measured idle timeout of the deployed path. A heartbeat is not a delivery acknowledgment. Detect stalled connections with write deadlines and client freshness checks.

Where this shows up

• Design: live sports commentary: one-way updates, with recovery when individual entries matter.
• Design: a chat app like WhatsApp: two-way messages and application acknowledgments.
• Design: a social media news feed: notifications can announce changes without carrying the complete feed.

Next, Scaling WebSocket connections to millions addresses how connection ownership and resource limits change across many servers.

Check your understanding

Summary