Badai percobaan ulang secara historis memengaruhi operasi bisnis dan kepercayaan merek. Meskipun penyetelan konfigurasi percobaan ulang dan anggaran percobaan ulang memberikan mitigasi yang berarti di tingkat layanan, keduanya dikonfigurasi secara manual dan kurang visibilitas ke dalam amplifikasi lintas layanan yang disebabkan oleh rantai dependensi yang dalam dan pola fan-out. Akibatnya, sulit untuk melindungi infrastruktur dari efek domino yang dipicu oleh kegagalan satu layanan yang lebih dalam di tumpukan.

Alasan utama adalah perilaku percobaan ulang saat ini tidak sadar konteks. Meskipun kita dapat mengontrol berapa banyak percobaan ulang yang terjadi, kita tidak dapat mengontrol secara tepat kapan itu terjadi. Ini berasal dari tantangan untuk secara andal membedakan antara kesalahan yang dihasilkan oleh suatu layanan dan yang hanya disebarkan melaluinya. Akibatnya, percobaan ulang diterapkan secara seragam daripada bersyarat. Pendekatan ini bekerja untuk kegagalan sementara atau tingkat rendah. Namun, selama degradasi sedang atau parah, itu menjadi kontraproduktif.

Percobaan ulang secara agresif terhadap layanan yang sudah berjuang meningkatkan beban, mempercepat kegagalan, dan memperkuat lalu lintas percobaan ulang di seluruh dependensi hulu. Apa yang dimulai sebagai gangguan lokal dapat dengan cepat meningkat menjadi insiden seluruh tumpukan—pada akhirnya menurunkan, atau dalam kasus terburuk, sepenuhnya merusak pengalaman pengguna akhir.

Seseorang mungkin berargumen bahwa kode kesalahan dari layanan hilir dapat diterjemahkan ke hulu untuk memberikan konteks untuk percobaan ulang. Meskipun secara teoritis mungkin, pendekatan ini tidak berskala di Uber karena fan-in dan fan-out yang besar, alur panggilan yang berkembang, dan kebutuhan akan perubahan adaptif yang sering. Oleh karena itu, kami mengembangkan mekanisme sadar konteks di infrastruktur bersama untuk menangani kesalahan dengan lebih efisien. Blog ini menjelaskan mekanisme tersebut.