Das Szenario: Dein Code ist in Ordnung: Das Problem liegt nicht bei dir
Deine App verhält sich plötzlich merkwürdig. Fehler häufen sich, Funktionen brechen zusammen. Du stellst dich auf einen Bug im eigenen System ein – aber alles sieht sauber aus.
Was ist also passiert? Der Fehler steckt nicht in deinem Code. Er kommt von weiter oben. Ein externer Dienst, auf den du angewiesen bist, ist ausgefallen oder hat angefangen, deine Anfragen zu drosseln. Vielleicht blockt eine externe API deine Requests, weil du ein Rate-Limit überschritten hast. So oder so: Deine App wartet auf Antworten, die nie ankommen – und die Nutzer sehen nur, dass etwas nicht funktioniert.
Zeit, das Problem zu verstehen, schnell gegenzusteuern – und sicherzustellen, dass es beim nächsten Mal nicht wieder passiert.
Es gibt zwei typische Szenarien:
- Ausfall auf externer Seite: Du verlässt dich auf einen Zahlungsdienstleister. Plötzlich wird er langsam oder fällt komplett aus. Dein Code ist bereit, die Zahlung abzuwickeln, aber es kommt nichts zurück. Der Checkout schlägt fehl. Die Umsätze brechen ein. Und du? Kannst nichts tun.
- Drosselung auf deiner Seite: Deine App erlebt einen Traffic-Peak – vielleicht wegen einer Kampagne oder weil du auf der Startseite gelandet bist. Du feuerst Anfragen an eine externe API. Doch die hat ein Limit. Wird es überschritten, drosselt oder blockt sie weitere Requests. Deine Nutzer sehen keine Rate-Limit-Warnung, sondern fehlerhafte Seiten.
In beiden Fällen ist das Ergebnis dasselbe: Eine zentrale Funktion fällt aus – und der Grund liegt nicht bei dir. Ein externer Dienst, auf den du dich verlässt, ist down oder zieht die Bremse. Jetzt bist du als Engineer gefragt: Was passiert hier – und wie kannst du den Schaden sofort begrenzen?
Der Quick-Fix: Den Einfluss minimieren
Wenn der Ausfall eintritt, zählt jede Minute. Das Ziel ist, die Auswirkungen für deine Nutzer so gering wie möglich halten. Hier sind ein paar Dinge, die du in diesem Moment tun kannst:
- Client-seitige Rate-Limits setzen: Drossle deine eigenen Anfragen, um unter den Drittanbieter-Limits zu bleiben, bis sich die Lage beruhigt.
- Deaktiviere abhängige Funktionen: Wenn Zahlungen nicht funktionieren, deaktiviere den Checkout. Wenn möglich, biete Alternativen wie “Nachnahme” an. Lass nicht zu, dass eine kaputte Integration die ganze App lahmlegt.
- Cache oder Default-Antworten nutzen: Für Lese-APIs kannst du zwischengespeicherte Daten ausliefern, statt fehlgeschlagene Anfragen zu zeigen. Etwas veraltete Informationen sind immer noch besser als eine Fehlermeldung.
- Circuit Breaker anpassen: Wenn du Circuit Breaker einsetzt, solltest du sie jetzt aktivieren oder neu justieren. Trenne fehlerhafte Dienste frühzeitig, um den Rest des Systems zu schützen.
Das Muster: Eine Abhängigkeit, viele Ausfälle
Das eigentliche Problem ist nicht der Ausfall selbst – sondern die Erwartung, dass externe Systeme immer verfügbar sind. Wenn du dich für zentrale Funktionen auf Drittanbieter verlässt, hängt dein Erfolg an ihrer Stabilität. Das geht gut – bis es eben nicht mehr geht.
Die langfristige Lösung: Für Ausfälle mitdenken
Du willst solche Probleme in Zukunft vermeiden – oder zumindest abfedern? Dann bau dein System so, dass es Ausfälle einkalkuliert:
- Redundanz schaffen: Für geschäftskritische Dienste solltest du mehr als einen Anbieter haben. Wenn ein Zahlungsdienstleister streikt, übernimmt der Backup.
- Infrastructure as Code (IaC): Automatisiere den Failover-Prozess. Wenn ein Anbieter dich drosselt oder ausfällt, kann dir IaC helfen, schnell und sicher zu einem anderen Anbieter zu wechseln.
- Circuit Breaker einbauen: Bombardiere eine fehlerhafte API nicht endlos weiter. Ein Circuit Breaker erkennt, wenn’s schiefläuft, und unterbricht die Verbindung rechtzeitig.
- Strategisches Caching: Hole Daten nicht ständig neu, wenn sie sich kaum ändern. Selbst kurzfristiges Caching reduziert Last und Abhängigkeiten.
- Batching und Debouncing: Mach nicht tausend kleine Anfragen, wenn eine große reicht. Batching spart Ressourcen – und hält dich unter dem Limit.
- Webhooks statt Polling: Polling kostet Performance. Webhooks liefern Updates nur, wenn es wirklich etwas Neues gibt. Nutze sie, wo immer möglich.
Bereit sein: Was Resilienz wirklich bedeutet
Ausfälle bei Drittanbietern sind genauso kritisch wie Bugs im eigenen Code – wenn nicht sogar schlimmer. Resilienz bedeutet, vorbereitet zu sein. Und zwar in drei Bereichen:
- Sichtbarkeit: Überwache externe Dienste. Kenne ihre Rate-Limits – bevor du sie versehentlich überschreitest.
- Anpassungsfähigkeit: Baue deine App so, dass sie flexibel auf Ausfälle reagiert: mit Fallbacks, temporären Deaktivierungen oder Retry-Logik.
- Proaktive Planung: Kenne deine Anbieter. Verstehe ihre Limits, kläre Eskalationswege – und weiß, wie du im Notfall eine Ansprechperson erreichst.
Kurz gesagt:
Externe Dienste bringen Power – aber auch Risiko. Wenn sie ausfallen, fällt auch deine App. Wenn du frühzeitig die richtigen Maßnahmen ergreifst, kannst du Ausfälle abfedern und ihre Folgen minimieren.
Behandle jede Integration als potenziellen Schwachpunkt. Und wenn der unvermeidliche Ausfall eintritt, bist du bereit – und nicht hilflos.
Stay tuned, Matthias
Dieser Blog Post ist Teil unserer mehrteiligen Serie in der wir typische Software Outages beschreiben und euch dabei helfen sie schnell zu beheben. Alle weiteren Posts findet ihr unter Vorwort: Wie Du das Chaos managest – Der richtige Umgang mit Software-Incidents | QualityMinds.
Schreib uns eine Mail – wir freuen uns auf deine Nachricht! hello@qualityminds.de oder auf LinkedIn