Kapan sampeyan bakal nganggo WebSocket, SSE, utawa long-polling tinimbang HTTP biasa?

Question

IT Interview Practice · Accepted Answer

HTTP biasa iku **request/response**: client takon, server njawab, rampung. Iku ora pas kanggo fitur **real-time** (chat, dashboard langsung, notifikasi, penyuntingan kolaboratif) ing endi *server* kudu ndorong data saben nduwé barang anyar. Pilihané iku cara kanggo ngakali model HTTP sing diwiwiti-client, ing sadawaning spektrum kompleksitas:

```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** iku cadangan sing mlaku ing endi waé: client gawé request normal sing server tahan mbukak nganti ana data, banjur client langsung njaluk manèh. Iku ngira-ira push ing HTTP biasa nanging mbuang siji siklus request saben pesen lan nambah latensi.

**SSE (Server-Sent Events)** iku stream **siji-arah** (server → client) sing ènthèng, distandarisasi ing sak response HTTP sing awèt suwé. Iku ideal nalika mung server sing ndorong — feed langsung, notifikasi, progres, token LLM streaming. Iku prasaja, mlaku ing HTTP/2 normal (ora ana infrastruktur khusus), lan nyambung manèh otomatis. Watesé: iku siji-arah lan mung-teks.

**WebSocket** ngupgrade sak koneksi HTTP dadi saluran TCP **full-duplex** sing awèt ing endi loro sisih ngirim kapan waé kanthi overhead saben-pesen sing minimal. Nganggo iku kanggo interaksi latensi-cendhak sing tenanan rong-arah: chat, game multiplayer, editor kolaboratif, trading. Ongkosé yaiku operasional — iku koneksi stateful sing awèt sing proxy, load balancer, lan autoscaler kudu dikonfigurasi kanggo iku, lan sampeyan kudu mbangun reconnection, heartbeat, lan backpressure dhéwé.

**Aturan jempol:** default menyang HTTP biasa; nganggo **SSE** kanggo streaming server→client; njangkau **WebSocket** mung nalika sampeyan pancèn butuh real-time rong-arah; njaga **long-polling** minangka cadangan universal.

## Kenapa iki penting

Milih transport real-time iku keputusan desain senior sing klasik ing endi jawaban naif ("nganggo WebSocket kanggo kabèh waé") biasané salah. Pewawancara pengin ndeleng yèn sampeyan nyocogaké piranti karo *pola komunikasi* — siji-arah vs rong-arah, kabutuhan latensi, volume pesen — lan yèn sampeyan nimbang **ongkos operasional** koneksi stateful sing awèt: sesi sticky, scaling, timeout proxy, lan logika reconnection. Ngakoni yèn SSE asring nyakup "server ndorong update" luwih prasaja tinimbang WebSocket, lan yèn long-polling tetep dadi cadangan sing kukuh, nunjukaké pengalaman production nyata tinimbang njangkau pilihan sing paling mencorong.

Kenapa iki penting

Pitakon sing gegandhengan