Filosofi Realtime Communication: Mengapa HTTP Polling Merupakan Utang Teknis Di Era Web Modern

Anomali HTTP Polling: Overhead Dan Pemborosan Resource

Pada awal era pengembangan web, mengimplementasikan interaksi interaktif dilakukan dengan mengirimkan permintaan HTTP secara berkala dari peramban ke server setiap beberapa detik (Short Polling). Meskipun secara sepintas terlihat berhasil, pendekatan ini menyimpan cacat arsitektur yang sangat merugikan ketika aplikasi berkembang pesat.

Setiap kali peramban melakukan request polling, koneksi HTTP baru atau reused connection harus membawa seluruh payload header HTTP. Informasi seperti User-Agent, Cookie session, token autentikasi Authorization: Bearer, serta metadata routing menghasilkan overhead antara 1 KB hingga 2 KB per permintaan. Jika data yang diperbarui hanya berukuran 15 byte JSON, maka lebih dari 98 persen bandwidth jaringan terbuang hanya untuk mengirimkan header.

"Melakukan HTTP Polling untuk memperbarui UI realtime ibarat mengetuk pintu rumah tetangga Anda setiap dua detik untuk bertanya apakah ada surat masuk. Protokol WebSocket menyediakan pintu terbuka yang memberi tahu Anda tepat ketika surat itu tiba."

MAYASTRA NAWALOKA, Realtime Systems Engineer

Dampak Pada CPU Server Dan Database Load

Kerugian terbesar dari HTTP Polling tidak hanya terletak pada konsumsi bandwidth jaringan, melainkan pada beban kerja pemrosesan server dan basis data. Ketika 10.000 pengguna aktif melakukan polling setiap 3 detik, server akan menerima sekitar 3.333 request per detik (RPS).

Sebagian besar dari permintaan tersebut (sering kali mencapai 95+ persen) mengembalikan respon kosong 304 Not Modified atau 200 OK dengan array kosong karena tidak ada perubahan data baru. Walaupun data tidak berubah, server tetap mengeksekusi kueri basis data, membuang alokasi thread CPU, dan menghabiskan connection pool.

Perbandingan Protokol: Polling vs SSE vs WebSocket

Untuk memahami karakteristik performa secara menyeluruh, berikut adalah perbandingan teknis antara empat opsi komunikasi pada aplikasi web:

Solusi Modern: Bi-Directional WebSocket & SSE Streaming

Protokol WebSocket memulainya melalui koneksi HTTP standar, yang kemudian ditingkatkan (upgraded) via HTTP 101 Switching Protocols menjadi koneksi TCP persisten full-duplex. Setelah pertukaran handshake selesai, data dikirim dalam bentuk frame biner atau teks yang berukuran sekecil 2 byte saja.

// Contoh Arsitektur WebSocket Connection Pool (Go Engine)
package main

import (
	"sync"
	"github.com/gorilla/websocket"
)

type ClientManager struct {
	clients    map[*websocket.Conn]bool
	broadcast  chan []byte
	register   chan *websocket.Conn
	unregister chan *websocket.Conn
	mutex      sync.RWMutex
}

func (manager *ClientManager) Start() {
	for {
		select {
		case conn := <-manager.register:
			manager.mutex.Lock()
			manager.clients[conn] = true
			manager.mutex.Unlock()
		case conn := <-manager.unregister:
			manager.mutex.Lock()
			if _, ok := manager.clients[conn]; ok {
				delete(manager.clients, conn)
				conn.Close()
			}
			manager.mutex.Unlock()
		case message := <-manager.broadcast:
			// Kirim data secara bersamaan ke jutaan klien terhubung
			manager.mutex.RLock()
			for conn := range manager.clients {
				conn.WriteMessage(websocket.TextMessage, message)
			}
			manager.mutex.RUnlock()
		}
	}
}

Arsitektur Skalabilitas WebSocket Dengan Redis Pub/Sub

Saat aplikasi berkembang hingga membutuhkan puluhan server peramban (horizontal scaling), status koneksi WebSocket (stateful connection) harus terkoordinasi antar instansi server. Strategi yang teruji secara industri adalah menggunakan Redis Pub/Sub atau NATS Messaging Backplane.

Ketika peristiwa baru terjadi di salah satu server backend, pesan dipublikasikan ke kanal Redis Pub/Sub. Seluruh server WebSocket yang berlangganan kanal tersebut akan menerima event secara simultan dan meneruskannya ke koneksi peramban masing-masing dalam kurun waktu kurang dari 5 milidetik.

Kapan Harus Menggunakan Server-Sent Events (SSE)?

Meskipun WebSocket sangat kuat, tidak semua fitur realtime membutuhkan komunikasi dua arah. Untuk kasus seperti papan skor olahraga, pembaruan status pengiriman, live log streaming, atau dashboard harga saham di mana klien hanya bertindak sebagai penerima pasif, Server-Sent Events (SSE) sering kali menjadi pilihan yang lebih unggul karena berjalan di atas protokol HTTP/2 atau HTTP/3 native dengan fitur auto-reconnection built-in.

MAYASTRA NAWALOKA

Software Engineering & System Architecture Expert

Spesialis rekayasa perangkat lunak berdedikasi tinggi dalam membangun platform web berkinerja tinggi, sistem terdistribusi, dan arsitektur backend yang scalable untuk perusahaan modern.