Banjir Request dan Seni Menahan Diri: Memahami Backpressure

Bayangkan ini: Kamu baru saja rilis fitur baru atau aplikasi sedang mengadakan flash sale. Awalnya semua aman. Traffic berjalan stabil. Lalu tiba-tiba, jumlah user meledak. Ribuan orang mencoba akses di detik yang sama (seperti fenomena war tiket konser).

Dan... servermu tumbang.

Bukan karena kodenya error. Bukan karena salah konfigurasi database. Tapi karena sistemmu tersedak.

Kondisi "tersedak" inilah yang dalam dunia engineering sering disebut dengan Backpressure.

Apa Itu Backpressure?

Sederhananya begini. Anggaplah API kita itu sebuah corong air. Kapasitas maksimal corong kita untuk mengalirkan air (request) ke bawah adalah 50 liter per detik.

Tiba-tiba, dari atas (klien web/mobile) mengguyur air sebanyak 100 liter per detik. Apa yang terjadi dengan 50 liter sisanya? Ia akan menggenang dan mengantri di atas corong.

Kalau di detik berikutnya masuk lagi 100 liter, genangan jadi makin tinggi. Makin lama, response time ke user makin lambat. Klien yang tidak sabar malah akan melakukan refresh (mengirim request baru lagi), yang justru membuat beban server makin parah berlipat ganda.

Akhirnya memori habis hanya untuk mencatat antrian, dan boom, aplikasi mati Out of Memory.

Ini adalah momen di mana kapasitas pihak yang memproses jauh lebih kecil dari jumlah request yang dikirimkan.

Lalu, gimana cara kita menangani banjir ini? Dari hasil ngulik belakangan, ada 5 strategi utama yang bisa dipakai.

5 Strategi Menghadapi Backpressure

1. Tambah Pekerja (Multi-Threading)

Cara paling awal: cek apakah aplikasimu sudah memaksimalkan thread (pekerja). Setiap bahasa pemograman punya cara sendiri. Kalau kerjanya bukan komputasi CPU yang berat (hanya sekadar hit database atau API pihak ketiga), coba naikkan jumlah thread-nya. Tadinya 10 pekerja, naikkan jadi 20 atau 30. Kapasitas memproses pun perlahan akan ikut naik.

2. Kloning Aplikasinya (Horizontal Scaling)

Ini solusi yang paling sering dipakai kalau budget bukan masalah. Satu server cuma kuat 50 request? Ya sudah, tambah satu server lagi di sebelahnya, lalu pasang Load Balancer di depan untuk membagi traffic. Sekarang kapasitas totalnya jadi 100 request. Kurang? Tambah server lagi. Solusi ini sangat cepat karena kita hampir tidak perlu mengubah baris kode sama sekali. Cuma butuh uang cloud tambahan.

3. Bikin Ruang Tunggu (Queue)

Kalau traffic naiknya cuma sedikit dan sesekali (misal dari 100 jadi 110), menambah server mungkin agak overkill dan membuang budget. Solusinya: buat antrian (Queue). Jadi request tidak langsung dilempar ke pekerja, melainkan disuruh duduk dulu di memori ruang tunggu. Pekerja yang sudah selesai tugasnya akan mengambil request berikutnya dari antrian ini. Data tidak hilang, cuma user butuh menunggu sedikit lebih lama.

4. Berani Bilang "Tidak" (Reject / Rate Limiting)

Terdengar ekstrem, tapi kadang ini sangat menolong. Gimana kalau traffic melonjak tidak masuk akal dari 100 jadi 1.000 request per detik? Ruang tunggu (Queue) pasti akan jebol juga. Di titik ini, kita harus berani menolak. Langsung drop atau reject request yang masuk berlebih, atau terapkan Rate Limiter. Lebih baik beberapa user mendapat respons "Sistem sedang sibuk, silakan coba lagi nanti", daripada server mati total dan berujung tidak ada satu pun user yang bisa bertransaksi.

5. Panggil Kurir Penengah (Message Broker)

Ini adalah arsitektur yang sekarang lagi populer (Event-Driven). Daripada klien nembak API kita secara langsung (synchronous), kita taruh "kurir" di tengah, seperti Kafka, RabbitMQ, atau sejenisnya. Klien cukup melempar datanya ke broker, lalu klien langsung mendapat respons "Oke, permintaanmu sedang diproses". Cepat dan tanpa loading lama. Di belakang layar, backend kita akan perlahan mengambil data dari broker tersebut sesuai dengan sisa tenaga yang ia punya. Broker bertindak sebagai buffer (bantalan) raksasa yang menahan ombak backpressure.

Tidak Ada Solusi yang Sempurna

Dari seringnya overthinking mikirin kelima cara di atas, saya sadar satu hal. Dalam system architecture, tidak ada silver bullet (solusi ajaib) yang menyelesaikan semua masalah secara gratis.

Mau pakai Horizontal Scaling? Siapkan budget. Mau pakai Message Broker? Siapkan waktu belajar untuk mengurus kompleksitas infra-nya. Mau pakai Reject? Siapkan kolaborasi dengan tim Frontend untuk bikin UI/UX error yang sopan agar user tidak marah-marah.

Menjadi engineer rupanya bukan sekadar tahu cara mengetik kode agar fitur jalan. Tapi juga tahu kapan harus memilih kompromi (trade-off) yang paling masuk akal untuk kondisi sistem kita saat ini.

---

Referensi

Backpressure - Senior Programmer Wajib Ngerti - Programmer Zaman Now