Wir stellen immer wieder fest, dass Systemabläufe die lange Zeit problemlos funktionierten, im Ablauf gestört werden. Das hat mit der Art der modernen Datenverarbeitung zu tun.
Unter einer API versteht ein Programmierer klassischerweise eine Sammlung von Funktionen. Wenn man eine Funktion aufruft, dann liefert die entweder Fehler oder Erfolg und bei Erfolg sind alle Dinge gemacht und die neuen Daten stehen zur Verfügung. Also kann man gleich mit neuen Ergebnissen weiterarbeiten, auch wenn man vorher 2 Minuten auf das Ergebnis warten musste.
Moderne APIs laufen aber nicht mehr lokal. Sie kommunizieren mit Microservices über das Internet. Eine Anfrage ins Internet wird aber nicht beliebig lange auf eine Antwort warten. Braucht der Microservice lange, dann wird die Verbindung unterbrochen. Eine Fehlermeldung ist die Folge, aber im Hintergrund kann der Microservice aber schon einen wichtigen Teil der Arbeit erledigt haben. Wie kommt man nun an die Daten?
Daher werden immer mehr Microservices so gebaut, dass man den Kern ausführt und Erfolg zurückmeldet, auch mit einigen Grunddaten. Die Operation ist erfolgreich abgeschlossen. Aber wenn dahinter noch umfangreichere Arbeiten anstehen, etwa synchronisieren diverser Datenbanken, kann es sein, dass das vollständige Ergebnis erst nach einer unbestimmten Zeit vorliegt. Das nennt man Asynchron. Und das ist eine vollständig andere Art der Programmierung. Wie erfahren wir also wann wir auf die kompletten neuen Daten zugreifen können?
Auch wenn sich eine API nicht ändert, kann sich das Ergebnis in der Nutzung total verändern. So sind bestehende Programme dann nicht mehr im gewohnten Flow. Und in diese Falle werden wir zunehmend mit stärkerer Nutzung von Microservices immer öfter tappen. Da hilft nur komplett neue Workflows zu erstellen. Das ist weder einfach noch ist das mal so eben schnell umgestellt.