Cara Uber Nahan Retry Storm yang Bisa Bikin Backend Lo Tumbang

Kita sering nulis retry di kode sebagai bentuk pertahanan. Kalau request gagal, coba lagi. Masalahnya, kalau semua klien melakukannya barengan tepat saat server lagi sekarat, yang ada bukannya penyembuhan, tapi pukulan beruntun yang bikin layanan tumbang total. Inilah yang namanya retry storm.

Uber nulis di blog engineering mereka soal cara mereka nahan masalah ini, dan isinya cukup praktis buat lo yang ngurus sistem terdistribusi.

Kenapa retry malah jadi masalah

Retry itu pedang bermata dua. Di satu sisi dia nyelametin request yang gagal sementara. Tapi begitu sistem udah kepenuhan, setiap retry malah nambah beban ke server yang lagi berjuang. Efeknya numpuk, karena retry dari pengguna, dari load balancer, dan dari service internal bisa saling nular.

Uber nunjukin bahwa retry yang gak diatur cuma memindahkan masalah. Server yang harusnya punya waktu buat pulih, malah terus digempur sampai benar-benar mati.

Pendekatan yang mereka pakai

Intinya, retry harus sadar konteks. Ada batas jumlah percobaan, ada jeda yang naik bertahap alias backoff, dan ada tambahan jitter biar retry dari banyak klien gak nyeruduk di detik yang sama. Tanpa jitter, backoff aja belum cukup, karena semua orang tetap datang tepat di waktu yang sama.

Mereka juga mikirin retry di level mana yang sehat. Gak semua elemen sistem harus punya kebijakan retry sendiri, karena lapisan yang saling menumpuk cuma memperbanyak percobaan yang ujungnya bikin beban berlipat.

Retry storm itu contoh klasik gimana niat baik di kode bisa jadi bumerang skala besar. Buat tim di Indonesia yang sistemnya mulai rame, ngatur retry dengan jitter dan budget itu pekerjaan kecil yang bisa nyelametin hari.

Sumber: How Uber Protects Against Retry Storms