Eine Integration, die unbegrenzt auf eine Antwort wartet, kann einen Kauf, eine Buchung oder einen internen Vorgang blockieren. Eine zu knapp bemessene Frist kann jedoch auch gültige Abläufe unterbrechen. Timeouts in Integrationen richtig festzulegen ist deshalb nicht nur eine Konfigurationsentscheidung: Es muss geklärt werden, wie lange der Geschäftsprozess warten kann, welche Rückmeldung Nutzerinnen und Nutzer erhalten und wie sich ungewisse Ergebnisse behandeln lassen.
Ein Timeout begrenzt die Zeit, in der eine Komponente auf eine Antwort wartet. Es beweist weder, dass das externe System seine Arbeit beendet hat, noch, dass der Vorgang fehlgeschlagen ist. Gute Zeitlimits legen fest, worauf gewartet wird, wann das Warten endet und was anschließend geschehen soll.
Die Frist muss sich nach den Anforderungen des Geschäftsprozesses richten
Ermitteln Sie zuerst, welcher Prozess von der externen Antwort abhängt und welche Folgen eine Verzögerung hat. Eine Autorisierung, die vor der Bestätigung eines Kaufs erforderlich ist, hat ein anderes Zeitfenster als die Aktualisierung eines Katalogs, die im Hintergrund erfolgen kann. Maßgeblich sollte nicht sein, „welcher Wert üblich ist“, sondern wie lange der Prozess warten kann, ohne Nutzer, Betrieb oder Datenkonsistenz zu beeinträchtigen.
Klären Sie für jede Abhängigkeit:
- Welche Entscheidung blockiert ist: etwa die Bestätigung einer Buchung oder die Anzeige eines Ergebnisses.
- Wer wartet: eine Person auf einer Benutzeroberfläche, ein API-Client, ein nächtlicher Prozess oder ein Betriebsteam.
- Was geschieht, wenn die Antwort nicht rechtzeitig eintrifft: Der Vorgang kann aufgeschoben, mit unvollständigen Informationen fortgeführt oder angehalten werden.
- Was „abgeschlossen“ bedeutet: dass eine Antwort eingegangen ist, der Anbieter den Auftrag angenommen hat oder die endgültige Wirkung bestätigt wurde.
Diese letzte Unterscheidung verhindert, dass eine technische Antwort mit dem fachlichen Ergebnis verwechselt wird. Ein Dienst kann einen Auftrag annehmen, ohne ihn bereits ausgeführt zu haben. Muss der Geschäftsprozess das endgültige Ergebnis kennen, ist es möglicherweise sinnvoller, den Status abzufragen oder später eine Benachrichtigung zu erhalten, statt die Wartezeit immer weiter zu verlängern.
Verbindungs-, Antwort- und Gesamtzeitlimits getrennt festlegen
Ein einzelnes Timeout kann verschleiern, an welcher Stelle sich Verzögerungen ansammeln. Sinnvoll ist es, Zeitlimits für die jeweiligen Wartephasen zu unterscheiden und zugleich eine maximale Gesamtdauer für den Vorgang festzulegen. So kann etwa der Verbindungsaufbau ein eigenes Limit haben, ebenso das Warten auf Daten nach dem Verbindungsaufbau. Die gesamte Abfolge – einschließlich abhängiger Aufrufe – muss jedoch in ein gemeinsames Zeitbudget passen.
Sind mehrere Dienste hintereinander eingebunden, muss die verfügbare Zeit auf sie verteilt werden. Es ist nicht sinnvoll, wenn jede Abhängigkeit einzeln die gesamte Wartezeit ausschöpft, die für Nutzerinnen und Nutzer vorgesehen ist: Zusammengenommen kann die Dauer dann das Zeitlimit des Prozesses überschreiten. Geben Sie eine gemeinsame Deadline, also einen verbindlichen Endzeitpunkt, weiter und lassen Sie jede Komponente nur die verbleibende Zeit nutzen. So arbeitet ein verspäteter Aufruf nicht weiter, wenn der auslösende Vorgang seinen Nutzen bereits verloren hat.
Bezeichnungen und Verhalten von Zeitlimits unterscheiden sich je nach Bibliothek und Plattform. Prüfen Sie, ob der konfigurierte Wert nur den Verbindungsaufbau, das Lesen einer Antwort, jeden einzelnen Versuch oder den gesamten Vorgang abdeckt. Berücksichtigen Sie auch Proxys, Load-Balancer und zwischengeschaltete Clients, die eigene Limits haben können. In der Praxis gilt entlang der Verbindung oft das restriktivste Zeitlimit.
Auch der Kontext zählt. Bei einer Interaktion mit Nutzerinnen und Nutzern braucht es meist eine schnelle Antwort oder einen klaren Übergang in einen ausstehenden Status. Ein Stapelverarbeitungsprozess kann ein größeres Zeitfenster zulassen, sofern er überwacht und begrenzt wird. Legen Sie die Fristen in beiden Fällen anhand der Prozessziele und beobachteter Latenzdaten fest, nicht anhand eines willkürlichen Werts.
Nach Ablauf der Frist: abbrechen, ausstehen lassen oder eingeschränkt fortfahren
Ein Timeout sollte eine vorgesehene Entscheidung auslösen und nicht als unbehandelte Ausnahme enden. Drei gängige Muster lassen sich je nach Vorgang auch kombinieren:
- Abbrechen und das Warten beenden: sinnvoll, wenn die Antwort keinen Nutzen mehr hat. Leiten Sie den Abbruch an laufende Aufgaben weiter, sofern Client und Dienst dies unterstützen, und geben Sie lokale Ressourcen frei.
- Den Vorgang als ausstehend markieren: geeignet, wenn der Anbieter die Arbeit asynchron erledigen kann. Geben Sie eine Referenz zur Nachverfolgung zurück oder speichern Sie diese und ermöglichen Sie eine spätere Statusabfrage.
- Eingeschränkt fortfahren: möglich, wenn eine sichere Alternative besteht, etwa aktuelle Daten anzuzeigen oder eine Aktualisierung aufzuschieben. Machen Sie kenntlich, welcher Teil nicht abgeschlossen werden konnte, und stellen Sie vorläufige Informationen nicht als bestätigt dar.
Das Beenden des Wartens macht einen entfernten Vorgang nicht rückgängig. Eine Anfrage kann den Anbieter kurz vor Ablauf des Zeitlimits erreicht haben. Der Server kann sie weiterverarbeiten, obwohl die Verbindung geschlossen wurde. Kennzeichnen Sie die Aktion daher nicht automatisch als fehlgeschlagen und bestätigen Sie Nutzenden nicht ohne ausreichende Belege, dass nichts geschehen ist.
Wenn der Vorgang nicht in einem ungewissen Zustand verbleiben darf, braucht es eine Möglichkeit, ihn abzufragen, abzugleichen oder durch eine kompensierende Aktion zu korrigieren. Ob ein tatsächlicher Abbruch möglich ist, hängt von den Fähigkeiten des entfernten Systems und der Art der Arbeit ab. Das muss geprüft und darf nicht vorausgesetzt werden.
Ein unbekanntes Ergebnis als eigenen Status behandeln
Läuft ein Timeout ohne Antwort ab, kann das Ergebnis „unbekannt“ sein: Es ist nicht klar, ob der Anbieter die Anfrage empfangen oder ausgeführt hat oder ob zuvor ein Fehler auftrat. Wird dieser Status von „fehlgeschlagen“ und „abgeschlossen“ unterschieden, lassen sich riskante Entscheidungen vermeiden – insbesondere bei Zahlungen, Buchungen, Lieferungen oder Änderungen an Konten.
Prüfen Sie vor einem erneuten Versuch mit möglichen Auswirkungen, ob der Integrationsvertrag einen Idempotenzschlüssel oder eine Statusabfrage anhand einer Kennung vorsieht. Idempotenz kann verhindern, dass eine Wiederholung doppelte Auswirkungen hat, aber nur, wenn sie für den betreffenden Vorgang implementiert und garantiert ist. Fehlt dieser Schutz, sollte der Status abgefragt oder der Fall vor einer Wiederholung einer kontrollierten Prüfung zugeführt werden.
Auch Wiederholungsversuche verbrauchen Zeit. Rechnen Sie sie in das Gesamtlimit ein und vermeiden Sie, dass jeder Versuch erneut eine vollständige, unabhängige Wartezeit erhält. Wiederholungen ohne Zeitbudget, mit ungünstig gewählten Abständen oder vervielfacht durch mehrere Komponenten können die Last genau dann erhöhen, wenn der Dienst beeinträchtigt ist. Für Aufgaben, die keine sofortige Antwort benötigen, eignen sich eine Warteschlange und ein Ablauf zur Nachverfolgung oft besser, als eine Verbindung offenzuhalten.
Status verständlich kommunizieren und eine klare Wiederherstellung ermöglichen
Die Mitteilung sollte dem Grad der Gewissheit entsprechen. Läuft der Vorgang noch, informieren Sie darüber, dass er aussteht. Ist das Ergebnis unbekannt, stellen Sie ihn weder als fehlgeschlagen noch als erfolgreich dar. Erklären Sie, was die Person tun kann: warten, den Status erneut abfragen oder den Support kontaktieren. Bitten Sie nicht ohne Warnung vor möglichen Duplikaten darum, eine folgenreiche Aktion zu wiederholen.
Auch interne Teams benötigen diesen Kontext. Erfassen Sie Korrelationskennungen, die betroffene Abhängigkeit, die Dauer, die Phase des Timeouts und das beobachtete Ergebnis. Unterscheiden Sie zwischen abgelaufenen Verbindungs- und Antwortzeitlimits sowie einer überschrittenen Gesamtdeadline. Nehmen Sie keine sensiblen Daten in unnötige Protokolle auf. Mit diesen Informationen kann der Support einen Fall untersuchen und die Technik herausfinden, welcher Abschnitt das Zeitbudget ausschöpft.
Zeitlimits anhand betrieblicher Signale testen und überprüfen
Ein Zeitlimit ist nicht schon deshalb validiert, weil die Integration unter normalen Bedingungen funktioniert. Testen Sie langsame Antworten, unterbrochene Verbindungen, Abbrüche, sporadische Fehler und Antworten, die erst nach Ablauf der Frist eintreffen. Prüfen Sie sowohl die Nutzererfahrung als auch die Auswirkungen beim Anbieter und den in Ihrem System gespeicherten Endstatus.
Beobachten Sie Latenzverteilungen, die Häufigkeit von Timeouts, ausstehende und unbekannte Vorgänge, Wiederholungsversuche sowie Störungen je Abhängigkeit. Mehr abgelaufene Zeitlimits können auf eine zu knapp bemessene Frist hindeuten, aber ebenso auf eine tatsächliche Beeinträchtigung des Anbieters, lokale Überlastung oder Probleme im Netzwerkpfad. Erhöhen Sie Timeouts nicht automatisch: Ermitteln Sie zuerst, wo die Verzögerung entsteht und welche Prozesse davon betroffen sind.
Dokumentieren Sie für jede Integration die Frist je Phase, das Gesamtzeitbudget, die Reaktion auf den Fristablauf, die Wiederholungsrichtlinie und den Wiederherstellungsmechanismus. Überprüfen Sie diese Vereinbarungen, wenn sich der Geschäftsablauf oder die beobachtete Latenz verändert. Das richtige Timeout ist weder das längste noch das kürzeste: Es schützt den Prozess, macht den Status verständlich und ermöglicht eine Wiederherstellung ohne doppelte Auswirkungen.