Când ai folosi WebSockets, SSE sau long-polling în locul HTTP-ului simplu?

Question

IT Interview Practice · Accepted Answer

HTTP-ul simplu este **request/response**: clientul întreabă, serverul răspunde, gata. Asta se potrivește prost cu funcționalitățile **real-time** (chat, dashboard-uri live, notificări, editare colaborativă) unde *serverul* trebuie să împingă date oricând are ceva nou. Opțiunile sunt moduri de a ocoli modelul inițiat-de-client al HTTP, de-a lungul unui spectru de complexitate:

```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** este soluția de rezervă care funcționează peste tot: clientul face o cerere normală pe care serverul o ține deschisă până are date, apoi clientul cere imediat din nou. Aproximează push-ul peste HTTP simplu, dar irosește un ciclu de cerere per mesaj și adaugă latență.

**SSE (Server-Sent Events)** este un stream **unidirecțional** (server → client) ușor, standardizat, peste un singur răspuns HTTP de lungă durată. Este ideal când doar serverul împinge — feed-uri live, notificări, progres, streaming de token-uri LLM. Este simplu, rulează peste HTTP/2 normal (fără infrastructură specială) și se reconectează automat. Limita: este unidirecțional și doar text.

**WebSockets** promovează o singură conexiune HTTP într-un canal TCP persistent, **full-duplex** unde ambele părți trimit oricând cu overhead minim per mesaj. Folosește-l pentru interacțiune cu adevărat bidirecțională, cu latență redusă: chat, jocuri multiplayer, editoare colaborative, trading. Costul este operațional — este o conexiune cu stare pentru care proxy-urile, load balancerele și autoscalerele trebuie configurate, și trebuie să construiești singur reconectarea, heartbeat-urile și backpressure-ul.

**Regulă de bază:** implicit folosește HTTP simplu; folosește **SSE** pentru streaming server→client; apelează la **WebSockets** doar când chiar ai nevoie de real-time bidirecțional; păstrează **long-polling** ca soluție de rezervă universală.

## De ce contează

Alegerea unui transport real-time este o decizie clasică de design de nivel senior, unde răspunsul naiv („folosește pur și simplu WebSockets pentru tot”) este de obicei greșit. Intervievatorii vor să vadă că potrivești unealta cu *tiparul de comunicare* — unidirecțional vs bidirecțional, nevoi de latență, volum de mesaje — și că cântărești **costul operațional** al conexiunilor cu stare, de lungă durată: sticky sessions, scalare, timeout-uri de proxy și logica de reconectare. Recunoașterea faptului că SSE acoperă adesea „serverul împinge actualizări” mai simplu decât WebSockets, și că long-polling rămâne o rezervă solidă, semnalează experiență reală de producție în loc de a apela la opțiunea cea mai spectaculoasă.

De ce contează

Întrebări conexe