Eine API-Integration funktioniert nicht zuverlässig, nur weil ein Request im Testsystem einmal mit Status 200 beantwortet wurde. Im Betrieb treten Timeouts, doppelte Nachrichten, Teilausfälle, Limits und unerwartete Daten auf. Retry, Idempotenz und Monitoring sorgen dafür, dass diese Situationen kontrollierbar bleiben.
Retry: erneut versuchen, aber bewusst
Ein Retry wiederholt einen fehlgeschlagenen Aufruf. Das ist sinnvoll bei vorübergehenden Problemen wie Netzwerkfehlern oder einer kurzzeitig überlasteten Gegenstelle. Nicht jeder Fehler darf wiederholt werden: Ungültige Eingaben werden durch zehn weitere Versuche nicht korrekt.
Gute Retry-Logik unterscheidet Fehlertypen, begrenzt die Anzahl der Versuche und vergrößert die Pause zwischen ihnen. Zufällige Abweichungen verhindern, dass viele Clients gleichzeitig erneut anfragen.
Idempotenz: doppelt gesendet, einmal ausgeführt
Wenn nach einem Timeout unklar ist, ob die Gegenstelle einen Auftrag verarbeitet hat, kann ein Retry denselben Vorgang doppelt auslösen. Bei Bestellungen, Zahlungen oder Buchungen ist das kritisch.
Ein Idempotenzschlüssel kennzeichnet den fachlichen Vorgang eindeutig. Die empfangende Seite speichert, dass dieser Schlüssel bereits verarbeitet wurde, und liefert bei Wiederholung dasselbe Ergebnis statt einer zweiten Ausführung. Beide Seiten müssen Lebensdauer und Gültigkeit des Schlüssels vereinbaren.
Monitoring: wissen, was gerade passiert
Logs allein reichen selten. Eine Integration braucht Kennzahlen zu Erfolgsquote, Laufzeit, Retry-Anzahl und Rückstau. Warnungen sollten an fachlich relevante Schwellen gekoppelt sein. Ein einzelner Fehler kann normal sein; ein wachsender Rückstau über zehn Minuten ist möglicherweise ein Incident.
Korrelations-IDs helfen, einen Vorgang über mehrere Systeme hinweg zu verfolgen. Personenbezogene Inhalte und Secrets gehören dabei nicht unkontrolliert in Logs.
Fehlerpfade zuerst mitdenken
Zu einer belastbaren Integration gehören Validierung, Timeouts, Rate Limits, Dead-Letter- oder manuelle Klärungswege und eine klare Verantwortung für Störungen. Der Happy Path ist nur der Anfang.