Retry-Stürme wirken sich historisch auf Geschäftsabläufe und Markenvertrauen aus. Während die Optimierung der Retry-Konfiguration und Retry-Budgets eine sinnvolle Abschwächung auf Serviceebene bieten, werden sie manuell konfiguriert und bieten keine Sichtbarkeit in die dienstübergreifende Verstärkung, die durch tiefe Abhängigkeitsketten und Fan-out-Muster verursacht wird. Infolgedessen kann es schwierig sein, die Infrastruktur vor dem Dominoeffekt zu schützen, der durch einen einzelnen Dienstausfall tiefer im Stack ausgelöst wird.

Ein Hauptgrund ist, dass das heutige Retry-Verhalten nicht kontextbewusst ist. Während wir steuern können, wie viele Wiederholungen auftreten, können wir nicht genau steuern, wann sie auftreten. Dies ergibt sich aus der Herausforderung, zuverlässig zwischen Fehlern zu unterscheiden, die von einem Dienst erzeugt werden, und solchen, die lediglich durch ihn weitergeleitet werden. Infolgedessen werden Wiederholungen einheitlich statt bedingt angewendet. Dieser Ansatz funktioniert für vorübergehende oder niederfrequente Ausfälle. Bei mäßiger oder schwerer Verschlechterung wird er jedoch kontraproduktiv.

Aggressives Wiederholen gegen einen bereits kämpfenden Dienst erhöht die Last, beschleunigt den Ausfall und verstärkt den Retry-Verkehr über vorgelagerte Abhängigkeiten. Was als lokalisierter Ausfall beginnt, kann sich schnell zu einem stackweiten Vorfall ausweiten—was letztendlich die Endbenutzererfahrung beeinträchtigt oder im schlimmsten Fall vollständig zerstört.

Man könnte argumentieren, dass Fehlercodes von nachgelagerten Diensten vorgelagert übersetzt werden könnten, um Kontext für Wiederholungen bereitzustellen. Obwohl theoretisch möglich, skaliert dieser Ansatz bei Uber aufgrund großer Fan-in- und Fan-out-Muster, sich entwickelnder Aufrufabläufe und der Notwendigkeit häufiger adaptiver Änderungen nicht. Daher haben wir einen kontextbewussten Mechanismus in der gemeinsamen Infrastruktur entwickelt, um Fehler effizienter zu behandeln. Dieser Blog erklärt den Mechanismus.