LEARN VISUALLY · API foundations
Polling, server-sent events or WebSockets?Choose by direction, frequency and recovery
Compare three ways to update a browser, then reason about reconnects, event identifiers and slow consumers using a synthetic sequence-recovery exercise.
A scoreboard, a chat window and a weekly report badge all change over time. They do not automatically need the same connection. Decide what moves, in which direction and how quickly it needs to arrive before choosing a protocol.
Jump to a section
The big picture
Open full-size diagram ↗
The diagram’s relationships are explained in the readable cards below. Open the full-size SVG to zoom.
Download branded diagram (SVG)Read the diagram
Three alternatives. Arrows show message direction; none promises replay or exactly-once effects.
Polling
Client asks; server responds
SSE
Server sends text events
WebSocket
Both ends send messages
Recovery
Reconnect plus state reconciliation
Begin with the actual update pattern
For a report badge that rarely changes, an occasional HTTP request may be enough. For a scoreboard with frequent server updates, repeatedly asking for unchanged state may be less attractive. For a chat session, both sides send messages. These are different communication needs. “Realtime” describes a desired experience; it does not specify one universal browser technology or a latency guarantee.
Ask whether a brief delay is acceptable, whether the server can hold connections and whether the user must send ongoing messages on the same channel. Include operating conditions: mobile networks disconnect, tabs close and intermediaries have timeouts. A design that works only while a laptop stays connected is incomplete.
Polling and long polling still use request/response
Ordinary polling makes repeated requests on a schedule. Long polling lets the server hold a request until a change or timeout, after which the client issues another. Long polling does not turn one HTTP response into an indefinitely bidirectional channel. It can reduce empty responses but introduces connection, timeout and reconnection behavior that must be handled.
Prevent overlapping polls from racing to replace a newer result with an older response. Use the service’s version or timestamp semantics where available and cancel obsolete requests. The polling interval is only one part of correctness; stale responses can make a fast interface display the wrong state.
Server-sent events send text events toward the browser
The EventSource interface receives a text/event-stream connection. The stream can contain named events, data and identifiers. Messages travel from server to client on that stream; browser actions can use separate HTTP requests. Do not describe SSE as unable to support any interactive application simply because the event stream itself is one-way.
EventSource includes reconnection behavior, and event identifiers can support recovery when the server implements it. A Last-Event-ID value does not force a server to retain or replay all history. Define what the identifier means and how to obtain a fresh snapshot when events are no longer available.
WebSockets support messages in both directions
A WebSocket connection lets client and server send messages over an established connection. It can suit chat or collaborative interactions, but the application still defines message schemas, authorization and delivery meaning. A successful send call is not an application-level confirmation that another person read or stored the message.
The classic browser WebSocket API does not automatically apply backpressure to incoming messages. If work arrives faster than it can be processed, memory or responsiveness can suffer. Bound buffers, reduce unnecessary updates and design an appropriate slow-consumer policy. Reconnecting does not by itself restore missed messages or session state.
Recover from a sequence gap deliberately
Our local fixture starts with last applied event 10, then receives 11, 11 and 13. It applies 11 once, ignores its duplicate and reports that event 12 is missing before applying 13. The application requests a snapshot rather than inventing the missing state. This is an application-level policy for the exercise, not a feature automatically provided by SSE or WebSocket.
Some applications can discard intermediate updates and keep only the latest snapshot; others need every operation in order. A scoreboard total and a financial ledger do not have the same loss tolerance. Choose the recovery rule based on what the data means, not the transport’s name.
Test the interrupted experience
Check the interface while connecting, disconnected, reconnecting and after a fresh snapshot. Show uncertainty rather than leaving a stale “live” badge forever. Validate permissions after reconnect where the service requires it, and avoid exposing private event content in public diagnostics. An accessible interface should communicate status with text, not only a colored dot.
Limits
The fixture tests ordering decisions without opening a network stream. It is not an SSE/WebSocket server, a browser compatibility test or a concurrency benchmark. The lesson compares common patterns; implementation details, authentication options, deployment limits and proxy buffering need current product documentation and real integration checks.
Work through the checked example
Input
Last applied=10; receive 11,11,13
Expected result
Apply 11 once Ignore duplicate 11 Gap before 13: request snapshot
What if it fails?
Application policy only; no SSE/WebSocket connection, automatic replay or network performance test.
Original synthetic teaching fixture. No remote connection or real account is used.
References
Sources used to check the explanations and examples are listed below.
Found a mistake? Send a correction with this lesson’s title, URL and disputed detail. No login needed.
Continue learning
Polling vs webhooks: ask for a change or receive an event? →
HTTP: one request, one response →
All visual lessons and practical guides →