Kapan Anda akan memakai WebSocket, SSE, atau long-polling alih-alih HTTP biasa?

Question

IT Interview Practice · Accepted Answer

HTTP polos bersifat **request/response**: client bertanya, server menjawab, selesai. Itu kurang cocok untuk fitur **real-time** (chat, dashboard langsung, notifikasi, penyuntingan kolaboratif) di mana *server* perlu mendorong data kapan pun ada sesuatu yang baru. Opsi-opsinya adalah cara menyiasati model HTTP yang diinisiasi-client, di sepanjang 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** adalah fallback yang bekerja di mana saja: client membuat request normal yang ditahan terbuka oleh server sampai ada data, lalu client segera meminta ulang. Ia mendekati push di atas HTTP polos tetapi memboroskan satu siklus request per pesan dan menambah latency.

**SSE (Server-Sent Events)** adalah stream **satu-arah** (server → client) yang ringan dan terstandarisasi di atas satu response HTTP yang berumur panjang. Ia ideal ketika hanya server yang mendorong — feed langsung, notifikasi, progres, streaming token LLM. Ia sederhana, berjalan di atas HTTP/2 biasa (tanpa infrastruktur khusus), dan menyambung ulang otomatis. Batasnya: ia satu-arah dan hanya-teks.

**WebSocket** meningkatkan satu koneksi HTTP menjadi kanal TCP **full-duplex** yang persisten di mana kedua sisi mengirim kapan saja dengan overhead per-pesan minimal. Pakai untuk interaksi yang benar-benar dua-arah dan berlatency rendah: chat, game multiplayer, editor kolaboratif, trading. Biayanya bersifat operasional — ia koneksi stateful yang harus dikonfigurasi pada proxy, load balancer, dan autoscaler, dan Anda harus membangun sendiri penyambungan ulang, heartbeat, dan backpressure.

**Aturan praktis:** default-kan ke HTTP polos; pakai **SSE** untuk streaming server→client; ambil **WebSocket** hanya ketika Anda benar-benar butuh real-time dua-arah; simpan **long-polling** sebagai fallback universal.

## Mengapa ini penting

Memilih transport real-time adalah keputusan desain senior klasik di mana jawaban naif ("pakai saja WebSocket untuk segalanya") biasanya salah. Pewawancara ingin melihat bahwa Anda mencocokkan alat dengan *pola komunikasi* — satu-arah vs dua-arah, kebutuhan latency, volume pesan — dan bahwa Anda menimbang **biaya operasional** koneksi stateful yang berumur panjang: sticky session, scaling, timeout proxy, dan logika penyambungan ulang. Menyadari bahwa SSE sering mencakup "server mendorong update" secara lebih sederhana daripada WebSocket, dan bahwa long-polling tetap fallback yang tangguh, menandakan pengalaman production nyata alih-alih memilih opsi yang paling mencolok.

Mengapa ini penting

Pertanyaan terkait