Backpressure pada Sistem Terdistribusi: Mencegah Layanan Kewalahan

Ketika jumlah permintaan meningkat lebih cepat daripada kemampuan sebuah layanan memprosesnya, antrean dapat membesar, waktu respons melambat, lalu kegagalan menyebar ke komponen lain. Menambah server tidak selalu menyelesaikan masalah, terutama jika hambatan sebenarnya berada pada basis data, layanan pihak ketiga, atau kapasitas koneksi. Salah satu pendekatan untuk menjaga sistem tetap terkendali adalah backpressure: mekanisme agar komponen yang bekerja lebih lambat dapat memberi sinyal kepada pengirim untuk mengurangi laju data atau permintaan.

Backpressure bukan sekadar membatasi trafik. Tujuannya adalah menyeimbangkan laju produksi dan konsumsi, sehingga sistem tidak menerima pekerjaan melebihi kapasitas yang mampu ditanganinya. Konsep ini berguna pada API, pemrosesan aliran data, antrean pekerjaan, dan arsitektur layanan mikro.

Apa itu backpressure?

Backpressure adalah cara komponen hilir menyampaikan bahwa kapasitasnya terbatas kepada komponen hulu. Misalnya, layanan pemroses gambar hanya mampu menyelesaikan 100 pekerjaan per detik, sementara API menerima 400 pekerjaan per detik. Tanpa pengendalian, antrean terus bertambah. Dengan backpressure, sistem dapat memperlambat pengiriman, menolak sebagian permintaan, atau meminta klien mencoba lagi setelah jeda.

Pada sistem streaming, backpressure bisa diwujudkan sebagai mekanisme permintaan: konsumen memberi tahu berapa banyak item yang siap diterima. Pada API web, penerapannya dapat berupa batas konkurensi, antrean berkapasitas tetap, respons sementara seperti HTTP 429 atau 503, dan petunjuk waktu tunggu melalui header yang sesuai. Detail implementasi berbeda, tetapi prinsipnya sama: kapasitas konsumen harus memengaruhi jumlah pekerjaan yang dikirim kepadanya.

Mengapa sistem bisa kewalahan?

Lonjakan trafik hanyalah salah satu penyebab. Konsumen dapat melambat karena kueri basis data mahal, koneksi habis, layanan eksternal mengalami gangguan, atau satu jenis pekerjaan memerlukan sumber daya jauh lebih besar daripada pekerjaan lain. Jika produsen terus mengirim data pada laju yang sama, antrean menjadi penyangga yang akhirnya menghabiskan memori, koneksi, atau ruang penyimpanan.

Masalah ini juga dapat menimbulkan efek berantai. Permintaan yang menunggu terlalu lama tetap memegang koneksi atau memori, sehingga lebih sedikit sumber daya tersedia untuk permintaan baru. Klien lalu melakukan retry secara bersamaan, menambah beban saat layanan justru sedang kesulitan. Inilah alasan backpressure perlu dirancang bersama timeout, retry dengan jeda, dan batas sumber daya.

Strategi backpressure yang umum

1. Gunakan antrean berbatas

Tentukan kapasitas antrean berdasarkan memori, ukuran pekerjaan, dan waktu tunggu yang masih dapat diterima. Antrean tanpa batas hanya menunda kegagalan dan sering membuatnya lebih besar. Saat antrean penuh, pilih perilaku yang jelas: menolak pekerjaan baru, menaruhnya pada penyimpanan persisten yang memang dirancang untuk itu, atau mengganti pekerjaan lama jika sifat datanya memungkinkan.

2. Batasi konkurensi

Batasi jumlah pekerjaan yang diproses bersamaan oleh komponen mahal, seperti basis data atau layanan eksternal. Batas ini mencegah ratusan permintaan membuka koneksi atau menjalankan kueri pada saat yang sama. Nilai terbaik perlu diuji melalui pengukuran; angka terlalu rendah membuang kapasitas, sedangkan angka terlalu tinggi dapat memperparah kontensi.

3. Tolak atau kurangi pekerjaan secara terukur

Ketika kapasitas penuh, penolakan yang cepat sering lebih aman daripada membiarkan permintaan menggantung. API dapat mengembalikan 429 untuk pembatasan permintaan atau 503 ketika layanan sementara tidak mampu melayani. Sertakan informasi retry yang masuk akal bila sesuai, dan dokumentasikan apakah operasi aman untuk diulang. Jangan menyuruh klien melakukan retry terus-menerus tanpa jeda.

4. Terapkan load shedding dan prioritas

Dalam kondisi darurat, sistem dapat membuang pekerjaan yang tidak penting agar fungsi inti tetap tersedia. Contohnya, pembaruan analitik yang bisa ditunda tidak perlu mengalahkan transaksi utama. Prioritas harus ditetapkan berdasarkan dampak bisnis, bukan hanya urutan kedatangan. Catat pekerjaan yang ditolak agar kehilangan data tidak luput dari perhatian.

5. Sesuaikan laju secara dinamis

Untuk beban yang berubah-ubah, pengendali dapat menyesuaikan batas konkurensi berdasarkan latensi, tingkat kesalahan, atau panjang antrean. Pendekatan adaptif perlu memiliki batas minimum dan maksimum, serta perubahan yang cukup halus agar tidak berosilasi. Mulailah dari aturan sederhana yang mudah diamati sebelum memperkenalkan algoritme yang lebih rumit.

Langkah menerapkan backpressure

1. Temukan titik hambatan. Petakan alur permintaan dan ukur komponen yang paling lambat, termasuk basis data, jaringan, dan layanan eksternal.
2. Tetapkan sasaran. Tentukan batas latensi, kapasitas antrean, tingkat penolakan yang dapat diterima, dan pekerjaan yang harus tetap tersedia saat beban tinggi.
3. Pilih perilaku saat penuh. Putuskan apakah pekerjaan akan ditolak, ditunda, diprioritaskan, atau disimpan secara persisten. Pastikan pilihan tersebut sesuai dengan sifat transaksi.
4. Atur timeout dan retry. Gunakan timeout yang realistis, exponential backoff, dan jitter agar klien tidak mengulang permintaan secara serempak. Untuk operasi yang dapat mengubah data, pertimbangkan idempotensi supaya retry tidak menghasilkan tindakan ganda.
5. Uji dengan beban bertahap. Simulasikan lonjakan dan perlambatan konsumen di lingkungan pengujian. Pastikan antrean tetap terbatas, penolakan terukur, dan layanan pulih setelah tekanan turun.

Metrik yang perlu dipantau

Pantau panjang dan usia antrean, laju masuk dibandingkan laju selesai, jumlah permintaan aktif, waktu tunggu, timeout, penolakan, penggunaan memori, serta tingkat retry. Panjang antrean saja tidak cukup: antrean kecil yang berisi pekerjaan sangat lambat dapat lebih bermasalah daripada antrean besar dengan pekerjaan ringan. Gabungkan metrik dengan log dan trace agar tim dapat menemukan komponen yang menjadi sumber perlambatan. Panduan OpenTelemetry untuk logs, metrics, dan traces dapat membantu merancang observabilitas tersebut.

Kesalahan yang perlu dihindari

• Menggunakan antrean tanpa batas sebagai solusi permanen.
• Mengaktifkan retry agresif tanpa backoff dan jitter.
• Menetapkan batas konkurensi tanpa mengukur kapasitas komponen hilir.
• Menolak semua jenis pekerjaan dengan cara yang sama, meskipun prioritasnya berbeda.
• Tidak memberi tahu klien apakah permintaan ditolak dan apakah aman untuk dicoba kembali.

Kesimpulan

Backpressure membantu sistem terdistribusi tetap stabil ketika laju permintaan melampaui kapasitas pemrosesan. Mulailah dengan antrean terbatas, batas konkurensi yang terukur, penolakan yang jelas, dan kebijakan retry yang aman. Pantau usia antrean serta latensi, lalu uji perilaku sistem ketika salah satu komponen melambat. Dengan pengendalian yang dirancang sejak awal, layanan dapat mengalami penurunan kapasitas secara terkendali alih-alih runtuh karena beban yang menumpuk.