Kapan Anda benar-benar butuh real-time — dan kapan polling diam-diam menang?

“Pokoknya harus real-time” adalah salah satu kalimat termahal di sebuah rapat awal proyek. Bunyinya seperti kebutuhan. Padahal biasanya itu sebuah perasaan — keinginan agar angka di layar terlihat segar — yang menyamar jadi keputusan arsitektur.

Bedanya penting, karena real-time bukan fitur yang tinggal ditambahkan. Ia postur yang harus ditanggung seluruh sistem: koneksi yang dijaga tetap hidup, logika menyambung ulang saat putus, presence dan penyebaran data ke banyak klien, penanganan saat satu klien lambat tak sanggup mengikuti, serta rencana operasional untuk jam dua dini hari ketika lapisan koneksi mulai goyah. Tak satu pun dari itu gratis, dan sebagian besarnya tak pernah muncul saat demo.

Maka sebelum berkomitmen, ada baiknya menanyakan hal yang lebih sempit daripada “ini harus real-time atau tidak?”. Pertanyaan yang berguna: berapa biayanya kalau data telat beberapa detik?

Tiga tingkatan yang jujur

Sebagian besar fitur masuk ke salah satu dari tiga tingkatan. Menamai tingkatannya lebih dulu bisa menghemat banyak biaya.

Tingkat 1 — Telat sedikit tak masalah (polling menang). Dashboard yang menyegarkan diri tiap 30 detik. Lencana notifikasi. Status pesanan yang berubah “sebentar lagi”. Kalau manusia tak akan menyadarinya — atau tak akan bertindak berbeda — dengan jeda 5–30 detik, Anda tidak butuh socket. Sebuah GET biasa pada interval tertentu, ditahan di cache edge, lebih murah dibangun, gampang dioperasikan, dan tetap selamat saat jaringan tersendat tanpa perlu kode menyambung ulang. Ini pilihan baku yang matang, dan memang sengaja tidak mentereng.

Tingkat 2 — Hitungan detik berarti (WebSocket sepadan). Penyuntingan bersama, obrolan langsung, tampilan lelang atau perdagangan, konsol operasi tempat operator bertindak atas apa yang ia lihat. Di sini, jeda 20 detik mengubah perilaku atau merusak kepercayaan. Kanal yang dijaga tetap hidup (WebSocket, atau Server-Sent Events untuk aliran satu arah) menjadi wajar — tetapi Anda kini menerima konsekuensi siklus hidup koneksi, presence, dan penyebaran data sebagai urusan utama, bukan tempelan.

Tingkat 3 — Di bawah satu detik, media, atau banyak-ke-banyak (ranah WebRTC). Audio/video langsung, berbagi layar, telemetri ala perangkat keras — apa pun yang anggaran latensinya dihitung dalam milidetik dan yang Anda pindahkan adalah media, bukan JSON. Ini tingkatan paling menuntut, sekaligus yang paling sering disebut tanpa benar-benar dibutuhkan. Ketika ia memang menjadi kebutuhan, ia tak kenal ampun — dan ia berpihak pada tim yang sudah pernah mengerjakannya.

Pertanyaan arsitekturnya jarang “real-time atau bukan”. Pertanyaannya: “tingkat yang mana, dan bisakah kita pertanggungjawabkan pilihan itu secara tertulis enam bulan dari sekarang?”

Pertanyaan yang menentukan tingkatannya

Beberapa pertanyaan ini memindahkan sebuah fitur antar-tingkat lebih cepat daripada perdebatan sepanjang apa pun:

• Siapa yang menanggapi pembaruan itu, dan secepat apa? Mesin yang menyelaraskan state bisa menoleransi hitungan detik. Manusia yang memutuskan untuk turun tangan mungkin tidak. Kalau tak ada yang bertindak atas kesegaran data itu, ia cuma hiasan.
• Berapa banyak klien melihat aliran yang sama? Satu penonton mudah di tingkat mana pun. Ratusan penonton serentak atas aliran langsung yang sama adalah persoalan penyebaran data yang diam-diam mendominasi rancangan.
• Ini data atau media? JSON lewat socket dan video lewat peer connection adalah dua disiplin engineering berbeda dengan mode kegagalan berbeda. Mencampuradukkan keduanya saat perencanaan adalah tempat anggaran berakhir sia-sia.
• Apa yang terjadi saat koneksi putus? Kalau jawabannya “pengguna muat ulang dan beres”, Anda kemungkinan ada di Tingkat 1. Kalau jawabannya “sesinya hilang”, Anda punya persoalan keandalan Tingkat 2/3 yang harus dirancang sejak hari pertama.

Berapa biaya Tingkat 3 sebenarnya — sebuah contoh nyata

Kami membangun platform proctoring berbasis browser untuk program asesmen pemerintah: banyak peserta menyalurkan webcam dan layar ke pengawas secara langsung, dengan perekaman yang siap diaudit, tanpa boleh ada aplikasi desktop. Itu jelas Tingkat 3 — di bawah satu detik, media, banyak-ke-banyak — dan itu keputusan yang tepat, karena pengawas yang meninjau rekaman setelah ujian tak bisa turun tangan saat ujian berlangsung.

Biayanya muncul persis di tempat Tingkat 3 selalu menagihnya: peer connection WebRTC dengan signaling WebSocket untuk pemantauan latensi rendah; perekaman sisi-browser dalam potongan yang bisa disambung kembali, sehingga segmen yang putus direkonsiliasi di server alih-alih membuat sesi hilang; konsol operator yang membuat satu orang sanggup mengawasi puluhan tile langsung sekaligus. Tak satu pun dari itu pantas untuk papan status Tingkat 1. Semuanya tak bisa ditawar di sini.

Pelajarannya bukan “real-time itu sulit”. Pelajarannya: tingkatan harus dipilih dengan sengaja, dipertanggungjawabkan secara tertulis, dan dipasangkan dengan tim yang sudah pernah membayar biayanya — karena bagian yang jebol justru bagian yang tak pernah muncul saat demo.

Langkah yang matang

Bakukan ke tingkat terendah yang jujur memenuhi kebutuhan, dan jadikan lompatan ke tingkat berikutnya sebuah keputusan tertulis dengan alasan yang menyertainya — bukan sekadar “bikin live” tanpa ditimbang. Sebagian besar produk butuh real-time jauh lebih sedikit daripada yang diasumsikan rapat awal. Yang memang benar-benar butuh Tingkat 3 akan lebih terbantu bila mengakuinya sejak dini dan merancang mode kegagalannya sejak awal.