Wanneer zou je WebSockets, SSE of long-polling gebruiken in plaats van gewoon HTTP?

Question

IT Interview Practice · Accepted Answer

Gewoon HTTP is **request/response**: de client vraagt, de server antwoordt, klaar. Dat past slecht bij **real-time** features (chat, live dashboards, notificaties, collaboratief bewerken) waar de *server* data moet pushen zodra hij iets nieuws heeft. De opties zijn manieren om HTTP's client-geïnitieerde model te omzeilen, langs een spectrum van complexiteit:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** is de fallback die overal werkt: de client doet een normale request die de server openhoudt tot hij data heeft, waarna de client meteen opnieuw vraagt. Het benadert push over gewoon HTTP maar verspilt een request-cyclus per bericht en voegt latency toe.

**SSE (Server-Sent Events)** is een lichtgewicht, gestandaardiseerde **eenrichtings**-stream (server → client) over één langlevende HTTP-response. Het is ideaal wanneer alleen de server pusht — live feeds, notificaties, voortgang, streaming LLM-tokens. Het is simpel, draait over normaal HTTP/2 (geen speciale infrastructuur), en verbindt automatisch opnieuw. De beperking: het is eenrichting en alleen tekst.

**WebSockets** upgraden één HTTP-connectie naar een persistent, **full-duplex** TCP-kanaal waar beide kanten op elk moment sturen met minimale overhead per bericht. Gebruik het voor echt bidirectionele, low-latency interactie: chat, multiplayer-games, collaboratieve editors, trading. De kosten zijn operationeel — het is een stateful connectie waarvoor proxies, load balancers en autoscalers geconfigureerd moeten worden, en je moet reconnection, heartbeats en backpressure zelf bouwen.

**Vuistregel:** neem standaard gewoon HTTP; gebruik **SSE** voor server→client-streaming; grijp naar **WebSockets** alleen wanneer je echt bidirectioneel real-time nodig hebt; houd **long-polling** als de universele fallback.

## Waarom het belangrijk is

Een real-time transport kiezen is een klassieke senior-ontwerpbeslissing waar het naïeve antwoord ("gebruik gewoon WebSockets voor alles") meestal verkeerd is. Interviewers willen zien dat je de tool afstemt op het *communicatiepatroon* — eenrichting vs bidirectioneel, latency-behoeften, berichtvolume — en dat je de **operationele kosten** van stateful, langlevende connecties afweegt: sticky sessions, scaling, proxy-timeouts, en reconnection-logica. Herkennen dat SSE vaak "server pusht updates" simpeler dekt dan WebSockets, en dat long-polling een robuuste fallback blijft, signaleert echte productie-ervaring in plaats van naar de meest flitsende optie grijpen.

Waarom het belangrijk is

Gerelateerde vragen