Die Hölle der Teilausfälle
In Microservices kann alles teilweise ausfallen. 1 von 8 Services ging down. Das Ergebnis war schlimmer als ein Komplettausfall.
Das Szenario:
- User-Flow: 8 Services in Reihe
- Service 6 (Empfehlungen): 50% Fehlerrate pro Versuch
- Kein Circuit Breaker, kein Fallback
- Retry-Policy: 3 Versuche mit je 30 Sekunden Timeout
Was die Nutzer erlebten:
- Etwa die Hälfte der Requests gelang im ersten Versuch
- Der Großteil des Rests gelang „irgendwann“ — nach ein oder zwei abgesessenen 30-Sekunden-Timeouts
- Rund 1 von 8 Requests verbrauchte alle drei Versuche und scheiterte nach 90+ Sekunden
- Nutzer luden neu → mehr Last auf einem ohnehin ausfallenden Service
- Threads, die in diesen 30-Sekunden-Wartezeiten blockierten, erschöpften die Pools aller vorgelagerten Services — alles degradierte
Das Schlimmste daran:
- Dashboards zeigten „Service 6: 50% healthy“
- Erlebnis für die Nutzer: 0% benutzbar
- Kein klarer Owner (wessen Schuld ist ein Teilausfall?)
Der Fix:
- Circuit Breaker auf allen ausgehenden Aufrufen
- Graceful Degradation (Seite ohne Empfehlungen anzeigen)
- Timeouts in ms gemessen, nicht in Sekunden
- Bulkhead-Pattern zur Isolation von Fehlern
Resilienz-Patterns wie diese gehören zum Standardumfang unserer DevOps- und Reliability-Arbeit — sie mitten im Incident nachzurüsten ist der teure Weg, sie zu lernen.
Lektion: In verteilten Systemen zuerst für Teilausfälle designen.
Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.