Synchronous versus Asynchronous Communication
Auf Antwort warten oder Nachricht hinterlassen
Die Idee und ihr Nutzen
Ein Kunde meldet im Portal seiner Versicherung einen Schaden, Fall 4711. Das Portal ist die Webseite der Versicherung für Schadenmeldungen. Ob der Vertrag diesen Schaden deckt, entscheidet ein anderes Programm, der Vertragsdienst, und das Portal muss beim Vertragsdienst nachfragen. Für diese Nachfrage gibt es zwei Möglichkeiten. Bei der synchronen Kommunikation ruft das Portal den Vertragsdienst auf und wartet, bis die Antwort da ist. Bei der asynchronen Kommunikation legt das Portal einen Prüfauftrag in eine Warteschlange und arbeitet sofort weiter. Ein anderes Programm arbeitet die Aufträge aus der Warteschlange der Reihe nach ab, und die Antwort kommt später. Welche Möglichkeit das Entwicklungsteam des Portals wählt, bestimmt, ob der Kunde noch während der Meldung oder erst später eine verbindliche Auskunft zur Deckung erhält.
Wie funktioniert es?
Für die Deckungsprüfung von Fall 4711 wählt das Entwicklungsteam des Portals eine der beiden Möglichkeiten. Die beiden Möglichkeiten sind keine zwei Schritte desselben Ablaufs. Bei der synchronen Kommunikation meldet der Kunde den Schaden, und das Portal fragt den Vertragsdienst direkt, ob der Schaden gedeckt ist. Das Portal wartet höchstens drei Sekunden auf die Antwort. Der Vertragsdienst antwortet normalerweise innerhalb einer Sekunde; drei Sekunden lassen ihm Spielraum, ohne dass der Kunde lange vor einer ladenden Seite sitzt. Eine solche Höchstdauer für das Warten heißt Zeitgrenze. Antwortet der Vertragsdienst rechtzeitig mit „gedeckt“, prüft das Portal weitere Voraussetzungen für eine sofortige Zahlungsfreigabe. Ohne rechtzeitige Antwort zeigt das Portal dem Kunden, dass die Deckung noch offen ist.
Bei der asynchronen Kommunikation meldet der Kunde denselben Fall an einem Tag nach einem Unwetter, an dem sehr viele Meldungen eingehen. Für die asynchrone Kommunikation kommen drei Bausteine hinzu. Die Falldaten sind der Datenbestand mit allen Fällen; dort steht zu jedem Fall ein Status. Die Warteschlange nimmt Prüfaufträge auf und hält sie bereit, auch wenn der Vertragsdienst gerade nicht erreichbar ist. Der Prüfprozess ist ein Programm, das im Hintergrund läuft und die Aufträge aus der Warteschlange abarbeitet. Das Portal speichert Fall 4711 mit dem Status „Deckung ungeprüft“ in den Falldaten und legt einen Prüfauftrag in die Warteschlange. Speichern und Einreihen müssen gemeinsam gelingen. Sonst gibt es eine gespeicherte Meldung ohne Prüfauftrag oder einen Prüfauftrag ohne Meldung. Der Kunde erhält sofort nur die Bestätigung „Ihre Meldung ist eingegangen“. Vor dem Auftrag für Fall 4711 stehen viele andere Prüfaufträge in der Warteschlange. Der Prüfprozess holt den Auftrag deshalb erst eine Stunde später ab, fragt den Vertragsdienst und setzt den Status von Fall 4711 in den Falldaten auf „gedeckt“. Der Kunde erhält eine E-Mail mit dem Ergebnis.
Bei der synchronen Kommunikation ist das Portal darauf angewiesen, dass der Vertragsdienst gerade läuft und innerhalb von drei Sekunden antwortet. Bei der asynchronen Kommunikation ruft nicht das Portal den Vertragsdienst auf, sondern der Prüfprozess. Der Vertragsdienst muss deshalb im Moment der Meldung nicht erreichbar sein. „Meldung angenommen“ heißt nicht „Deckung geprüft“. Bis das Ergebnis vorliegt, darf das Portal nichts anzeigen oder entscheiden, was eine bestätigte Deckung voraussetzt, zum Beispiel keine Zahlungsfreigabe anstoßen. Der Kunde kann den Stand im Portal abrufen oder bekommt eine Benachrichtigung. Keine der beiden Möglichkeiten macht den Vertragsdienst schneller oder zuverlässiger.
Bleibt bei der synchronen Kommunikation die Antwort aus, weiß das Portal nicht, ob der Vertragsdienst die Prüfung abgebrochen oder nur zu langsam geantwortet hat. Das Portal zeigt deshalb „Deckung noch offen“ und nicht „nicht gedeckt“. Scheitert bei der asynchronen Kommunikation die Prüfung im Prüfprozess, bleibt der Auftrag erhalten. Eine festgelegte Regel bestimmt, wie oft der Prüfprozess den Auftrag wiederholt und wer den Auftrag danach prüft.
Synchron oder asynchron: zwei Alternativen für Fall 4711
Wann ist es sinnvoll und wann nicht?
Synchrone Kommunikation passt
- Der Vertragsdienst antwortet zuverlässig innerhalb von drei Sekunden. Dann erfährt der Kunde noch während der Meldung, dass Fall 4711 gedeckt ist. Bei asynchroner Kommunikation erführe der Kunde das erst später per E-Mail, und Warteschlange und Prüfprozess müssten zusätzlich betrieben werden.
- Der Kunde muss sofort wissen, ob sein Schaden gedeckt ist. Eine spätere Nachricht hilft ihm dann nicht.
- Niemand ist dafür da, den Status der Fälle zu überwachen, gescheiterte Aufträge zu bearbeiten und Nachfragen der Kunden zu beantworten. Bei asynchroner Kommunikation entstünden dann Vorgänge, deren Stand niemand kennt.
Synchrone Kommunikation passt nicht
- Die Deckungsprüfung dauert länger als die drei Sekunden, die das Portal wartet, oder es kommen Lastspitzen vor. Ein Beispiel ist ein Tag nach einem Unwetter mit sehr vielen Meldungen. Wartet das Portal dann auf den Vertragsdienst, wartet auch der Kunde oder erhält eine Fehlermeldung. Dann wählt das Entwicklungsteam des Portals die asynchrone Kommunikation. Das Portal nimmt jede Meldung sofort an, und der Prüfprozess fragt den Vertragsdienst später, einen Prüfauftrag nach dem anderen. Kein Kunde sitzt vor einer ladenden Seite oder erhält eine Fehlermeldung.
- Der Vertragsdienst ist zeitweise nicht erreichbar. Dann wählt das Entwicklungsteam des Portals die asynchrone Kommunikation. Das Portal nimmt Meldungen auch während des Ausfalls an. Der Prüfauftrag bleibt in der Warteschlange, bis der Vertragsdienst wieder erreichbar ist, und der Prüfprozess erledigt ihn danach. Die asynchrone Kommunikation baut auf Messaging auf, dem Austausch von Nachrichten über Warteschlangen.
- Ein Aufruf läuft über eine Kette mehrerer Dienste, die alle gleichzeitig verfügbar sein müssen. Ruft das Portal den Vertragsdienst auf und der Vertragsdienst wiederum einen dritten Dienst, addieren sich die Wartezeiten. Der Ausfall eines einzigen Dienstes lässt dann den ganzen Vorgang scheitern. Auch dann wählt das Entwicklungsteam des Portals die asynchrone Kommunikation. Das Portal wartet auf keinen Dienst der Kette, denn den Vertragsdienst ruft der Prüfprozess auf. Fällt ein Dienst aus, bleibt der Prüfauftrag in der Warteschlange, und die Meldung des Kunden scheitert nicht.
- Der Kunde soll meist sofort ein Ergebnis erhalten, aber der Vertragsdienst antwortet nicht immer rechtzeitig. Mit synchroner Kommunikation allein erhält der Kunde in diesen Fällen nur „Deckung noch offen“. Dann baut das Entwicklungsteam des Portals eine Mischform: Das Portal fragt zuerst synchron mit kurzer Zeitgrenze und legt nur dann einen Prüfauftrag an, wenn keine rechtzeitige Antwort kommt. Der Kunde erhält so in den meisten Fällen sofort ein Ergebnis und sonst eine Eingangsbestätigung. Die Mischform braucht den direkten Aufruf und zusätzlich Warteschlange und Prüfprozess, die betrieben werden müssen. Außerdem muss festgelegt sein, was gilt, wenn die Antwort auf den synchronen Aufruf nach der Zeitgrenze doch noch eintrifft und der Prüfauftrag schon angelegt ist.
Nachteile und typische Fehler
Bei asynchronen Abläufen braucht jeder Vorgang einen sichtbaren Status, und Kunden brauchen eine Möglichkeit, diesen Stand nachzuverfolgen. Außerdem muss festgelegt sein, was geschieht, wenn ein Prüfauftrag doppelt in der Warteschlange ankommt oder immer wieder scheitert. Asynchrone Abläufe sind schwerer nachzuvollziehen. Wer einen Fehler bei Fall 4711 sucht, muss Portal, Warteschlange und Prüfprozess einzeln ansehen, weil Meldung und Ergebnis eine Stunde auseinanderliegen. Die Warteschlange und der Prüfprozess müssen außerdem betrieben und überwacht werden. Bei der synchronen Kommunikation muss das Entwicklungsteam die Zeitgrenze so wählen, dass der Kunde nicht zu lange wartet und der Vertragsdienst trotzdem in den meisten Fällen rechtzeitig antwortet.
Typische Fehler und woran man sie erkennt:
- Angenommene Meldung als geprüft dargestellt: Das Portal zeigt nach der asynchronen Annahme bereits „gedeckt“ an oder stößt eine Zahlungsfreigabe an, bevor die Prüfung stattgefunden hat. Erkennbar ist das an Fällen mit dem Status „Deckung ungeprüft“, zu denen der Kunde schon eine Zusage erhalten hat.
- Meldung ohne Prüfauftrag: Das Portal speichert den Fall, aber das Einreihen des Prüfauftrags scheitert. Der Prüfprozess erhält dann nie einen Auftrag zu diesem Fall, und niemand prüft die Deckung. Ebenso kann das Einreihen gelingen und das Speichern scheitern; dann holt der Prüfprozess einen Auftrag zu einem Fall, der in den Falldaten fehlt. Erkennbar ist das an Fällen, die dauerhaft „Deckung ungeprüft“ bleiben, oder an Prüfaufträgen zu Fällen, die es nicht gibt.
- Fehlende Zeitgrenze: Das Portal wartet bei der synchronen Kommunikation ohne Zeitgrenze auf den Vertragsdienst. Ist der Vertragsdienst langsam, warten auch die Kunden. Erkennbar ist das an lange ladenden Seiten, sobald der Vertragsdienst verzögert antwortet.
- Blockierte Warteschlange: Ein Prüfauftrag scheitert immer wieder, zum Beispiel weil der Vertragsdienst zu diesem Fall keinen Vertrag findet und einen Fehler meldet. Der Prüfprozess versucht den Auftrag ohne Grenze erneut. Solange der Prüfprozess diesen einen Auftrag wiederholt, holt er die Aufträge dahinter nicht ab. Erkennbar ist das an einer wachsenden Warteschlange und an Kunden, die auch nach Stunden keine Nachricht erhalten.
Weiterführend
Verwandte Ansätze
- Outbox Pattern: speichert den Fall und den Prüfauftrag in derselben Datenbanktransaktion und überträgt den Auftrag erst danach in die Warteschlange. So entsteht keine gespeicherte Meldung ohne Prüfauftrag.
- Timeout: begrenzt bei der synchronen Kommunikation die Wartezeit, hier auf drei Sekunden.
- Request Reply: schickt Anfrage und Antwort als Nachrichten, wenn ein Ergebnis zurückkommen soll, ohne dass der Aufrufer währenddessen wartet.
- Dead Letter Queue: nimmt Prüfaufträge auf, die wiederholt scheitern, damit sie die übrigen Aufträge nicht aufhalten und ein Mensch sie prüfen kann.
Quellen
- Microsoft: Interservice communication in microservices: vergleicht synchrone Aufrufe und asynchrone Nachrichten, unter anderem bei Ausfällen des Empfängers, bei Ketten von Aufrufen und beim Ausgleich von Lastspitzen durch Warteschlangen.
- Chris Richardson: Messaging: begründet asynchrone Nachrichten damit, dass bei synchronen Aufrufen Aufrufer und aufgerufener Dienst während der ganzen Anfrage verfügbar sein müssen, und nennt den zusätzlichen Betrieb des Nachrichtenvermittlers als Nachteil.