Hvornår ville du bruge WebSockets, SSE eller long-polling i stedet for almindelig HTTP?

Question

IT Interview Practice · Accepted Answer

Almindelig HTTP er **request/response**: klienten spørger, serveren svarer, færdig. Det passer dårligt til **realtids**-features (chat, live dashboards, notifikationer, samtidig redigering), hvor *serveren* skal pushe data, når som helst den har noget nyt. Mulighederne er måder at komme uden om HTTP's klient-initierede model, langs et spektrum af kompleksitet:

```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** er reserveløsningen, der virker overalt: klienten laver en normal request, som serveren holder åben, indtil den har data, hvorefter klienten straks re-requester. Det tilnærmer push over almindelig HTTP, men spilder en request-cyklus pr. besked og tilføjer latency.

**SSE (Server-Sent Events)** er en letvægts, standardiseret **enkeltrettet** stream (server → klient) over en enkelt langlivet HTTP-response. Den er ideel, når kun serveren pusher — live feeds, notifikationer, fremdrift, streaming af LLM-tokens. Den er enkel, kører over normal HTTP/2 (ingen speciel infrastruktur) og genopretter automatisk. Begrænsningen: den er enkeltrettet og kun tekst.

**WebSockets** opgraderer en enkelt HTTP-forbindelse til en persistent, **full-duplex** TCP-kanal, hvor begge sider sender når som helst med minimal overhead pr. besked. Brug det til ægte tovejs, lav-latency-interaktion: chat, multiplayer-spil, samtidige editorer, trading. Prisen er driftsmæssig — det er en stateful forbindelse, som proxies, load balancers og autoscalere skal konfigureres til, og du skal selv bygge reconnection, heartbeats og backpressure.

**Tommelfingerregel:** default til almindelig HTTP; brug **SSE** til server→klient-streaming; grib til **WebSockets** kun, når du virkelig har brug for tovejs-realtid; hold **long-polling** som den universelle reserveløsning.

## Hvorfor det betyder noget

At vælge en realtids-transport er en klassisk senior-designbeslutning, hvor det naive svar ("bare brug WebSockets til alt") som regel er forkert. Interviewere vil se, at du matcher værktøjet til *kommunikationsmønsteret* — enkeltrettet vs tovejs, latency-behov, beskedvolumen — og at du vejer de **driftsmæssige omkostninger** ved stateful, langlivede forbindelser: sticky sessions, skalering, proxy-timeouts og reconnection-logik. At erkende, at SSE ofte dækker "server pusher opdateringer" enklere end WebSockets, og at long-polling forbliver en robust reserveløsning, signalerer reel production-erfaring frem for at gribe efter den mest prangende mulighed.

Hvorfor det betyder noget

Relaterede spørgsmål