Pilih kanal real-time

Pertanyaan

Kanal apa yang cukup buat ngirim pembaruan ke klien, dan kapan WebSocket beneran dibutuhkan?

Setelah baca ini, kamu bisa milih antara polling, long polling, SSE, dan WebSocket dari kebutuhan pengiriman, lalu ngitung berapa koneksi dan request yang bakal ditanggung server.

Prasyarat dan contoh

Kamu sudah paham request HTTP dan latensi (M03), serta cara ngitung beban dan kapasitas (M01). Nggak perlu pernah bikin server WebSocket.

Bayangin aplikasi pesan dengan 100.000 pengguna aktif bersamaan. Tiap pengguna perlu tahu ada notifikasi baru. Kalau klien polling tiap 5 detik, server nerima 20.000 request per detik. Rata-rata cuma beberapa persen yang bawa data baru, sisanya respons kosong yang tetap bayar TLS, header, autentikasi, dan query.

Sebaliknya, kalau tiap pengguna cuma dapat satu notifikasi per jam, 100.000 koneksi yang terus terbuka juga bukan gratis. Tiap koneksi makan memori, file descriptor, dan keepalive. Pertanyaannya bukan "mana yang paling modern", tapi pembaruan itu datang seberapa sering, ke arah mana, dan seberapa telat boleh.

Mekanisme

Empat kanal, dari yang paling sederhana:

1. Polling. Klien nanya tiap N detik. Stateless, gampang di-cache, gampang di-load-balance, dan jalan lewat proxy apa pun. Telat paling lama N detik, dan beban naik linear sama jumlah klien walau nggak ada data baru. Cocok buat status yang berubah jarang, misalnya "pembayaran sudah masuk?" selama maksimal 2 menit.

2. Long polling. Klien nanya, server menahan request sampai ada data atau timeout (misalnya 30 detik), lalu klien langsung nanya lagi. Latensi pengiriman rendah, tapi tiap klien tetap memegang satu request terbuka, dan tiap pembaruan ongkosnya satu siklus request penuh. Pembaruan yang datang beruntun bisa terlewat kalau nggak ada kursor (lihat M13.03).

3. Server-Sent Events (SSE). Satu request HTTP yang responsnya stream teks, arahnya server ke klien. Browser menyambung ulang otomatis dan ngirim header Last-Event-ID, jadi server bisa lanjut dari event terakhir yang diterima. Cocok buat notifikasi, skor langsung, dan progres job. Keterbatasan: satu arah, hanya teks, dan di HTTP/1.1 browser membatasi sekitar 6 koneksi per domain, jadi buka banyak tab bisa kehabisan jatah. HTTP/2 melonggarkan batas itu.

4. WebSocket. Setelah handshake HTTP Upgrade, koneksi jadi dua arah dengan framing sendiri. Cocok buat chat, permainan, dan editor kolaboratif, di mana klien juga sering ngirim. Ongkosnya: reconnect, autentikasi ulang, heartbeat, dan backpressure harus kamu bikin sendiri, dan beberapa proxy atau load balancer menutup koneksi yang diam, misalnya setelah 60 detik.

Hitung koneksinya. Dengan 100.000 koneksi dan sekitar 20 KB memori per koneksi buat buffer dan state, itu 2 GB sebelum aplikasi nyimpen apa pun. Satu node bisa pegang ratusan ribu koneksi idle, tapi kamu tetap butuh batas file descriptor, tuning kernel, dan rencana deploy: restart satu node memutus semua koneksinya sekaligus (lihat M13.02).

Fallback. Apa pun kanalnya, jalur sinkronisasi lewat HTTP biasa ("kasih semua setelah kursor X") harus ada. Kanal real-time itu optimasi pengiriman, bukan sumber kebenaran.

Saat rancangan ini gagal

• WebSocket buat semuanya. Tim pakai WebSocket cuma buat notifikasi satu arah, lalu harus bikin sendiri reconnect, resume, dan penanganan proxy yang SSE kasih gratis.
• Polling terlalu rapat. Interval 1 detik di 50.000 klien itu 50.000 request per detik, hampir semuanya kosong. Database kena beban baca yang nggak ada manfaatnya.
• Proxy memutus koneksi diam. Load balancer menutup koneksi yang idle 60 detik. Klien kelihatan "terhubung" tapi sebenarnya sudah mati, dan pembaruan hilang tanpa error.
• Kanal jadi sumber kebenaran. Kalau pesan hanya dikirim lewat koneksi dan nggak disimpan, klien yang terputus 20 detik kehilangan pesan selamanya.

Contoh tandingan: tim menolak koneksi persisten karena "terlalu rumit" dan polling tiap 2 detik. Di 200.000 pengguna puncak, itu 100.000 request per detik buat data yang jarang berubah. Memilih yang sederhana tetap perlu dihitung.

Latihan

Pilih kanal dan tulis alasannya buat tiap kasus:

1. Halaman status pembayaran, rata-rata dibuka 90 detik, 30.000 pengguna bersamaan.
2. Skor pertandingan langsung, 400.000 penonton, pembaruan tiap 2 detik buat semua.
3. Chat grup dengan indikator mengetik, 50.000 pengguna bersamaan.
4. Dashboard internal yang diperbarui tiap menit, 40 pengguna.

Lihat pembahasan+

1. Polling tiap 3 sampai 5 detik, atau SSE. Di interval 5 detik itu 6.000 request per detik selama pembayaran belum selesai, dan berhenti saat selesai. Toleransi telat beberapa detik cukup. SSE juga boleh kalau infrastruktur sudah mendukungnya.
2. SSE (atau WebSocket) di belakang CDN atau lapisan fan-out. Data satu arah dan sama buat semua, jadi cuma satu pesan per 2 detik yang perlu disebar. Polling di 400.000 klien itu 200.000 request per detik, jelas lebih mahal.
3. WebSocket. Klien ngirim pesan dan sinyal mengetik, jadi dua arah dengan frekuensi tinggi. Siapkan heartbeat dan jalur sinkronisasi HTTP.
4. Polling tiap 30 detik. 40 pengguna itu kurang dari 2 request per detik. Koneksi persisten cuma nambah komponen.

Polanya: arah data dan frekuensi dulu, jumlah klien kedua, baru kenyamanan teknologi.

Terkait

• Lanjut ke M13.02 Kelola koneksi buat reconnect, heartbeat, dan buffer klien.
• Pengiriman pesan yang tahan terputus dibahas di M13.03 Kirim pesan chat.
• Latensi dan timeout dari M03 dan beban dari M01 dipakai di sini sebagai dasar hitungan.

Catatan

• Asumsi: klien browser atau mobile biasa, jaringan seluler yang bisa putus kapan saja.
• Angka memori per koneksi hanya contoh hitungan. Ukur di runtime dan konfigurasimu sendiri.
• Yang nggak dibahas: WebTransport, push notification OS, dan MQTT.
• Perilaku SSE dan batas koneksi mengikuti spesifikasi HTML dan HTTP umum. Cek dokumentasi browser dan proxy yang kamu pakai.
• Terakhir ditinjau: 26 Oktober 2026.