Wie verändern sich Wartezeit und Verfügbarkeit, wenn die Rechnung zugeschaltet wird?

Die Wartezeit steigt von 450 auf 1250 ms, die Verfügbarkeit sinkt von etwa 99,3 auf etwa 98,8 Prozent (illustrative Werte).

Der Zahlungsanbieter fällt aus. Was geschieht mit dem Checkout?

Zahlung wartet auf den Anbieter, Bestellung auf die Zahlung. Der Checkout steht bis zum Timeout nach 3000 ms und schlägt dann fehl.

Soll die PDF-Erzeugung der Rechnung im synchronen Checkout bleiben?

Vorteil: Der Beleg liegt sofort vor. Nachteil: 800 ms mehr Wartezeit und ein Ausfallrisiko mehr. Empfehlung: asynchron erzeugen, der Checkout braucht den Beleg nicht für die Bestätigung.

MusterKapitel II · Kommunikation · Baustein 2 von 9

Synchrone Kommunikation

Synchrone Kommunikation koppelt eine Anfrage zeitlich an ihre Antwort. Der Aufrufer wartet bis zum Ergebnis, Fehler oder Ende seiner Wartefrist.

Von Michael Meierhoff · Meierhoff Systems

WartepfadAlle Aufrufe, auf die gewartet wird.
Verfügbarkeit multipliziertJede Abhängigkeit senkt das Gesamtergebnis.
TimeoutBegrenzt das Warten bei Ausfall.

Einordnung

Warum das wichtig ist

Wer synchron aufruft, wartet. Wartezeiten addieren sich, Verfügbarkeiten multiplizieren sich: Jede Abhängigkeit im Checkout verlängert den Wartepfad und kann ihn bei Ausfall blockieren. Zeitlich entkoppelte Verarbeitung behandelt Asynchrone Kommunikation.

Dieser Baustein erklärt unmittelbare Anfrage-Antwort-Beziehungen. Für spätere Verarbeitung siehe Asynchrone Kommunikation.

Auf einen Blick · Aufruf mit Warten auf Antwort

Der Client ruft Dienst A, der wiederum Dienst B ruft; jeder wartet, bis die Antwort zurückkommt.

Shop-Beispiel · Wartekette

Wartekette im Checkout

Im modularen Monolithen fragt Bestellung Lager und Zahlung direkt an. Das Zahlungsmodul ruft den externen Zahlungsanbieter über das Netzwerk auf.

So liest du das Bild

Wartepfad Die zugeschalteten Aufrufe; ihre Millisekunden ergeben die Wartezeit.
Verfügbarkeit multipliziert Die Verfügbarkeit des Checkouts sinkt mit jedem zugeschalteten Aufruf.
Timeout Bei ausgefallenem Anbieter wartet die Bestellung bis 3000 ms.

Bestellungwartet auf

Wartezeit des Checkouts: 450 ms
Verfügbarkeit des Checkouts: 99,30 %

Wartezeiten addieren sich, Verfügbarkeiten multiplizieren sich: Jeder zugeschaltete Aufruf macht den Checkout langsamer und weniger verfügbar.

Zeiten und Verfügbarkeiten illustrativ

Schalte Aufrufe zu oder ab und lass den Zahlungsanbieter ausfallen; Zeiten und Verfügbarkeiten sind illustrativ.

Nutzen & Grenzen

Hilft, wenn

Eine Anfrage-Antwort-Interaktion gibt dem Aufrufer das Ergebnis zurück, das er für seinen nächsten Schritt benötigt.
Eine unmittelbare fachliche Rückmeldung lässt sich mit synchroner Kommunikation direkt zurückgeben.
Kontrollierbare Zeitbudgets begrenzen den Wartepfad; bleibt die Gegenstelle im Budget erreichbar, genügt das für den nächsten Schritt.

Grenzen

Jede weitere synchrone Abhängigkeit verlängert den Wartepfad und senkt die Gesamtverfügbarkeit des Checkouts.
Nach einem Timeout bleibt unklar, ob die Gegenstelle gearbeitet hat; Timeout begrenzt das Warten, Retry steuert Folgeversuche.
Ein ausgefallener externer Anbieter blockiert den Aufrufer bis zum Ende der Wartefrist, auch wenn alle internen Module laufen.

In der Praxis

Verteile das Zeitbudget über alle synchronen Abhängigkeiten und lege eine klare Antwortgrenze fest. So bleibt für die gesamte Interaktion eine überprüfbare Höchstwartezeit.
Unterscheide fachliche Ablehnung, Transportfehler und Timeout im Vertrag. Der Aufrufer kann dann angemessen abbrechen, nachfragen oder einen Status anzeigen.
Wiederhole nur Operationen mit sicherer Semantik und begrenzter Zahl an Versuchen. Timeout behandelt Wartegrenzen; Retry steuert erneute Aufrufe.

Ausführliche Erklärung lesen

Bei synchroner Kommunikation wartet der Aufrufer auf die Antwort oder eine festgelegte Zeitgrenze. Das Ergebnis kann unmittelbar in den laufenden Ablauf einfließen. Latenz und Ausfall der Gegenstelle wirken dadurch direkt auf den Aufrufer.

Timeouts belegen nur das Ausbleiben einer rechtzeitigen Antwort, nicht den fachlichen Ausgang. Zeitbudgets, Fehlerantworten und zulässige Wiederholungen sind Teil des Vertrags. Lange synchrone Ketten summieren Wartezeit und koppeln Verfügbarkeit über mehrere Komponenten.

Timeout begrenzt die Wartezeit, legt den Commit-Ausgang aber nicht fest; Retry braucht deshalb eine sichere Wiederholungssemantik.

REST über HTTP und gRPC sind verbreitete Formen synchroner Aufrufe. Beide brauchen Timeouts, damit der Aufrufer nicht unbegrenzt wartet.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Wie verändern sich Wartezeit und Verfügbarkeit, wenn die Rechnung zugeschaltet wird?
Lösung mit Begründung ansehen
Die Wartezeit steigt von 450 auf 1250 ms, die Verfügbarkeit sinkt von etwa 99,3 auf etwa 98,8 Prozent (illustrative Werte).
AnwendenAuf eine neue Lage übertragen
Der Zahlungsanbieter fällt aus. Was geschieht mit dem Checkout?
Lösung mit Begründung ansehen
Zahlung wartet auf den Anbieter, Bestellung auf die Zahlung. Der Checkout steht bis zum Timeout nach 3000 ms und schlägt dann fehl.
BewertenEine Alternative abwägen
Soll die PDF-Erzeugung der Rechnung im synchronen Checkout bleiben?
Lösung mit Begründung ansehen
Vorteil: Der Beleg liegt sofort vor. Nachteil: 800 ms mehr Wartezeit und ein Ausfallrisiko mehr. Empfehlung: asynchron erzeugen, der Checkout braucht den Beleg nicht für die Bestätigung.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Kommunikation & APIs: Asynchrone Kommunikation.

9 Bausteine

Weiter mitAsynchrone Kommunikation