Pilih transport

Pertanyaan

Protokol dan pola komunikasi mana yang cocok buat kebutuhan ini, dan apa yang dikorbankan?

Setelah baca ini, kamu bisa milih antara request/response HTTP, gRPC, dan streaming buat sebuah kasus, lalu nyebut jaminan yang kamu dapat dan masalah yang masih harus kamu tangani sendiri.

Prasyarat dan contoh

Kamu sudah bisa nelusuri request dari browser sampai respons (M02.01), termasuk biaya handshake dan RTT.

Tiga kebutuhan yang kelihatan mirip tapi beda: (1) aplikasi mobile ngambil daftar pesanan, (2) service pembayaran manggil service fraud 3 kali per transaksi dengan latensi ketat, (3) dashboard driver nampilin posisi kurir yang berubah tiap detik. Menyamaratakan ketiganya jadi "REST over HTTP" itu mungkin, tapi bukan berarti ketiganya sama-sama cocok.

Mekanisme

TCP vs UDP. TCP ngasih aliran byte yang berurutan dan andal: ada retransmisi, kontrol aliran, dan kontrol kemacetan. Harganya handshake, dan head-of-line blocking: satu paket hilang menahan semua byte setelahnya sampai paket itu dikirim ulang. UDP cuma ngirim datagram: tanpa urutan, tanpa retransmisi, tanpa handshake. Aplikasi yang milih UDP harus ngurus sendiri apa yang dia butuh, atau memang nggak butuh. Contoh yang cocok: suara dan video real-time (paket telat lebih jelek daripada paket hilang) dan query DNS yang kecil. QUIC (dasar HTTP/3) dibangun di atas UDP tapi nambah keandalan, enkripsi, dan stream independen, sehingga satu paket hilang cuma nahan stream-nya.

Request/response HTTP. Klien nanya, server jawab, selesai. Cocok buat sebagian besar API publik: cacheable (GET), gampang di-debug, didukung semua klien. Biayanya: tiap interaksi harus diinisiasi klien, dan format teks seperti JSON lebih gede dan lebih lambat di-parse daripada format biner.

gRPC. Jalan di atas HTTP/2, pakai Protocol Buffers sebagai format biner, dan kontrak didefinisikan di file .proto. Dapat: payload lebih kecil (sering 2 sampai 5 kali lebih kecil dari JSON, tergantung data), kode klien tergenerate, dan empat pola: unary, server streaming, client streaming, bidirectional. Biayanya: browser butuh gRPC-Web atau proxy, debug butuh tool khusus, dan load balancing butuh perhatian karena satu koneksi HTTP/2 yang panjang membawa banyak request (dibahas di M02.05).

Streaming dan alternatifnya. Buat data yang berubah terus ada beberapa pilihan:

| Pola | Arah | Cocok buat | | -------------------- | ----------------------- | ------------------------------------------------------ | | Polling | klien tarik berkala | data berubah jarang, toleran 10 sampai 60 detik | | Long polling | klien tarik, server tahan | notifikasi jarang, infrastruktur HTTP biasa | | Server-Sent Events | server → klien | feed satu arah, otomatis reconnect | | WebSocket | dua arah | chat, kolaborasi, interaksi dua arah |

Contoh angka: posisi 10.000 kurir, update tiap detik. Polling tiap 1 detik oleh dashboard 500 admin = 500 request/detik walau nggak ada perubahan. SSE: 500 koneksi terbuka, server dorong hanya saat ada update. Tapi 500 koneksi panjang artinya memori dan file descriptor per koneksi, dan deploy ulang memutus semuanya sekaligus.

Kompatibilitas dan evolusi. gRPC dan Protocol Buffers punya aturan kompatibilitas jelas (nomor field nggak boleh dipakai ulang). JSON fleksibel tapi kontraknya longgar. Detailnya masuk M03.

Saat rancangan ini gagal

• WebSocket buat data yang jarang berubah. Ribuan koneksi idle makan memori dan harus di-reconnect setelah tiap deploy, padahal polling tiap 30 detik cukup.
• Polling agresif. 20.000 klien polling tiap 2 detik = 10.000 request/detik, sebagian besar kosong. Beban naik linear dengan jumlah klien, bukan jumlah perubahan.
• gRPC lewat load balancer L4 tanpa distribusi per-request. Semua request dari satu klien nempel ke satu server karena satu koneksi HTTP/2 panjang. Satu instance panas, sisanya nganggur.
• UDP tanpa urusan keandalan. Pesan penting (transaksi) lewat UDP polos bisa hilang tanpa ada yang tahu.
• Reconnect serempak. Server restart, 50.000 klien streaming sambung ulang di detik yang sama. Tanpa backoff dan jitter, mereka numpuk jadi lonjakan beban baru.

Contoh tandingan: pindah ke gRPC buat API publik yang dipakai browser dan pihak ketiga menambah proxy dan beban dukungan tanpa manfaat yang terukur. Payload JSON 2 KB nggak pernah jadi bottleneck sebelum database.

Latihan

Pilih pola komunikasi buat tiga kasus tadi, dan sebut satu risiko untuk tiap pilihan:

1. Aplikasi mobile ngambil daftar pesanan (sekali saat layar dibuka).
2. Service pembayaran manggil service fraud, 3 kali per transaksi, p99 harus di bawah 20 ms, keduanya internal.
3. Dashboard admin nampilin posisi 10.000 kurir, update tiap detik, 500 admin terbuka.

Lihat pembahasan+

1. Request/response HTTP (REST/JSON). Interaksi diinisiasi klien, sekali, bisa di-cache dan mudah di-debug. Risiko: payload JSON besar di jaringan mobile, jadi pagination dan field yang dibatasi perlu diatur (M03).
2. gRPC unary dengan koneksi dipakai ulang. Payload kecil, kontrak ketat, tanpa overhead handshake per call, dan keduanya internal sehingga keterbatasan browser nggak relevan. Risiko: distribusi beban. Satu koneksi HTTP/2 panjang butuh load balancing level request, dan deadline harus diteruskan supaya 3 panggilan nggak melewati 20 ms.
3. Server-Sent Events (atau WebSocket kalau admin juga ngirim perintah). Data searah dari server, perubahan sering tapi pola-nya push. 500 koneksi itu kecil. Daripada 500 request/detik polling, server cukup nulis ke 500 koneksi. Risiko: deploy memutus 500 koneksi sekaligus, jadi klien butuh reconnect dengan backoff dan jitter, dan server perlu kirim snapshot awal setelah sambung ulang.

Jawaban yang bagus menyebut pola yang dipilih, alasan dari arah dan frekuensi, serta mode gagalnya.

Terkait

• M02.01 Telusuri request dari browser menjelaskan biaya handshake yang jadi dasar perbandingan di sini.
• M02.05 Alihkan trafik dari server yang tidak sehat bahas masalah koneksi panjang di balik load balancer.
• M03 Kontrak API dan retry yang aman membahas spesifikasi, versioning, dan retry di atas transport yang kamu pilih.
• Lab L02 belum tersedia.

Catatan

• Asumsi: jaringan biasa tanpa NAT yang agresif memutus koneksi idle; klien modern.
• Rasio ukuran payload Protocol Buffers vs JSON tergantung bentuk data. Ukur payload kamu sendiri.
• Yang nggak dibahas: message broker, GraphQL, WebRTC, dan detail kontrol kemacetan TCP.
• Terakhir ditinjau: 26 Oktober 2026.