Wann würdest du WebSockets, SSE oder Long-Polling statt einfachem HTTP verwenden?

Question

IT Interview Practice · Accepted Answer

Einfaches HTTP ist **Request/Response**: Der Client fragt, der Server antwortet, fertig. Das passt schlecht zu **Echtzeit**-Features (Chat, Live-Dashboards, Notifications, kollaboratives Editieren), bei denen der *Server* Daten pushen muss, wann immer er etwas Neues hat. Die Optionen sind Wege, das clientinitiierte Modell von HTTP zu umgehen, entlang eines Spektrums der Komplexität:

```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** ist der Fallback, der überall funktioniert: Der Client stellt einen normalen Request, den der Server offen hält, bis er Daten hat, dann fragt der Client sofort erneut. Es approximiert Push über einfaches HTTP, verschwendet aber einen Request-Zyklus pro Nachricht und fügt Latenz hinzu.

**SSE (Server-Sent Events)** ist ein leichtgewichtiger, standardisierter **Einweg**-Stream (server → client) über eine einzige langlebige HTTP-Response. Es ist ideal, wenn nur der Server pusht — Live-Feeds, Notifications, Fortschritt, streamende LLM-Tokens. Es ist einfach, läuft über normales HTTP/2 (keine spezielle Infrastruktur) und reconnected automatisch. Die Einschränkung: Es ist einseitig und nur Text.

**WebSockets** upgraden eine einzige HTTP-Verbindung zu einem persistenten, **full-duplex** TCP-Kanal, bei dem beide Seiten jederzeit mit minimalem Overhead pro Nachricht senden. Nutze es für wirklich bidirektionale, latenzarme Interaktion: Chat, Multiplayer-Games, kollaborative Editoren, Trading. Der Preis ist operativ — es ist eine stateful Verbindung, für die Proxies, Load Balancer und Autoscaler konfiguriert sein müssen, und du musst Reconnection, Heartbeats und Backpressure selbst bauen.

**Faustregel:** Standardmäßig einfaches HTTP; nutze **SSE** für server→client-Streaming; greife zu **WebSockets** nur, wenn du wirklich bidirektionale Echtzeit brauchst; halte **Long-polling** als universellen Fallback bereit.

## Warum es wichtig ist

Die Wahl eines Echtzeit-Transports ist eine klassische Senior-Design-Entscheidung, bei der die naive Antwort ("nutze einfach WebSockets für alles") meist falsch ist. Interviewer wollen sehen, dass du das Werkzeug an das *Kommunikationsmuster* anpasst — einseitig vs. bidirektional, Latenzbedarf, Nachrichtenvolumen — und dass du die **operativen Kosten** stateful, langlebiger Verbindungen abwägst: sticky sessions, Skalierung, Proxy-Timeouts und Reconnection-Logik. Zu erkennen, dass SSE oft "Server pusht Updates" einfacher abdeckt als WebSockets, und dass Long-polling ein robuster Fallback bleibt, signalisiert echte Produktionserfahrung statt zum auffälligsten Werkzeug zu greifen.

Warum es wichtig ist

Ähnliche Fragen