API-Orchestrierung

Vor anderthalb Jahrzehnten trug dieses Problem einen anderen Namen. Unternehmen verbanden ihre Systeme über einen Enterprise Service Bus, und eigene Teams beschäftigten sich den ganzen Tag damit, Aufrufe zwischen Anwendungen zu koordinieren. Mit dem Aufstieg von REST und Microservices galt diese Welt als überwunden. Jeder Dienst sollte für sich stehen und über eine sauber geschnittene API erreichbar sein.

Genau diese Zerlegung bringt das alte Thema in neuer Form zurück. Wenn eine fachliche Aufgabe mehrere dieser kleinen Dienste benötigt, muss jemand ihre Aufrufe wieder ordnen. Eine Bestellung prüft den Lagerbestand, autorisiert eine Zahlung und stößt den Versand an, und diese drei Schritte gehören zu einem Vorgang. Wer diesen Vorgang zusammenhält, betreibt API-Orchestrierung, auch wenn im Team niemand das Wort benutzt.

Was API-Orchestrierung bedeutet

Orchestrierung beantwortet im Kern eine einfache Frage. Wer ist dafür verantwortlich, dass mehrere Service-Aufrufe in der richtigen Reihenfolge und mit den richtigen Daten ablaufen? Bei einem einzelnen Aufruf stellt sich diese Frage nicht. Sobald jedoch mehrere Aufrufe zusammengehören, braucht es eine Stelle, die den Gesamtablauf kennt.

Das Bestellbeispiel macht das greifbar. Der Lagerbestand wird geprüft, danach die Zahlung autorisiert und zuletzt der Versand angestoßen. Jeder dieser Schritte ist ein eigenständiger Service mit separater API. Keiner von ihnen kennt den vollständigen Ablauf. Der Lager-Service hat keine Kenntnis von der Zahlung, der Zahlungs-Service keine vom Versand. Erst eine orchestrierende Schicht verbindet die drei zu einem Vorgang, der entweder vollständig gelingt oder kontrolliert abbricht.

Diese Schicht übernimmt drei Aufgaben. Sie legt die Reihenfolge fest, reicht Ergebnisse weiter, etwa die Bestell-ID an den Versand, und entscheidet, was bei einem Fehler geschieht. Schlägt die Zahlung fehl, darf der Versand nicht starten. Diese Logik gehört weder in den Lager- noch in den Zahlungs-Service, weil beide nur ihren eigenen Teil überblicken. Orchestrierung ist damit die Antwort auf eine Lücke, die durch die Zerlegung in Microservices überhaupt erst entsteht.

Wichtig ist die Frage, wo diese Steuerung sitzt. Sie kann in einem der beteiligten Services liegen, der die anderen aufruft, oder in einer eigenen Schicht, die ausschließlich den Ablauf kennt. Beide Varianten sind Orchestrierung. Der Unterschied liegt in der Sichtbarkeit. Liegt die Steuerung in einem fachlichen Service, vermischt sich die Koordination mit dessen eigentlicher Aufgabe. Eine eigene Schicht trennt beides und macht den Ablauf als solchen erkennbar.

Warum das Thema zurückkehrt

Drei Entwicklungen bringen das Thema zurück. Die erste ist die schiere Zahl der Dienste. Wo früher ein Monolith eine Aufgabe intern erledigte, sind heute oftmals fünf oder zehn Services beteiligt. Die zweite ist die Wiederverwendung. Derselbe Bestellablauf wird aus einer Web-Anwendung, einer mobilen App und einer Partner-Schnittstelle ausgelöst, und überall muss die Reihenfolge stimmen. Die dritte Entwicklung sind KI-Agenten, die Geschäftsprozesse selbstständig ausführen sollen und dafür eine verlässliche Beschreibung des Ablaufs brauchen.

Besonders die Wiederverwendung treibt das Thema. Solange ein Ablauf nur an einer Stelle existiert, fällt die fehlende Orchestrierung kaum auf. Sobald derselbe Vorgang aus mehreren Kanälen angestoßen wird, vervielfacht sich das Risiko. Jede Kopie der Reihenfolge kann sich unbemerkt anders entwickeln, und eine Änderung am Ablauf muss an mehreren Stellen gleichzeitig nachgezogen werden. Eine gemeinsame Orchestrierung verhindert, dass dieselbe Logik in leicht abweichenden Varianten nebeneinander läuft.

In den meisten Systemen existiert Orchestrierung dabei längst, nur unausgesprochen. Sie versteckt sich in dem Service, der zufällig als Erster aufgerufen wird und von dort die anderen anstößt. Dieser Service trägt dann eine Verantwortung, für die er ursprünglich nicht vorgesehen war. Plötzlich kennt er die Reihenfolge, die Fehlerbehandlung und die Daten aller anderen. Aus einem klar geschnittenen Dienst wird unbemerkt ein kleiner Monolith, der die Abläufe seiner Nachbarn mitführt.

An dieser Stelle lohnt ein Blick zurück auf den Enterprise Service Bus. Er ist als zentrale, schwergewichtige Middleware in Verruf geraten, weil er zu viel Logik an einer Stelle bündelte und Teams ausbremste. Die heutige Antwort sieht anders aus. Orchestrierung wird als dünne, klar umrissene Schicht verstanden, die nur den Ablauf kennt und die fachliche Arbeit weiterhin den einzelnen Services überlässt. Eine Rückkehr zum ESB ist damit nicht gemeint. Das Ziel ist die bewusste Trennung zwischen der Arbeit und ihrer Koordination.

Orchestrierung, Choreographie und die Alternativen

Orchestrierung ist einer von mehreren Ansätzen, mehrere Services zu verbinden. Die Begriffe werden in der Praxis oft vermischt, meinen aber Verschiedenes. Ein kurzer Überblick ordnet sie ein.

Die Unterschiede sind groß genug, dass jeder Ansatz einen eigenen Blick verdient. Wann sich die beiden Grundmodelle gegenüberstehen, behandelt der Vergleich Orchestrierung vs. Choreographie. Wie sich Orchestrierung von einem Gateway abgrenzt, klärt API-Orchestrierung vs. API-Gateway. Und worin sich die drei oft vermischten Begriffe unterscheiden, zeigt Composition. Für den Überblick genügt eine Faustregel. Orchestrierung steuert aktiv einen Ablauf, während die anderen Ansätze andere Probleme lösen.

Die Bausteine einer Orchestrierung

Unabhängig vom Werkzeug besteht ein orchestrierter Ablauf aus denselben Bausteinen. Am Anfang stehen die Schritte, von denen jeder einen Service aufruft. Zwischen den Schritten fließen Daten, weil ein späterer Aufruf häufig ein Ergebnis eines früheren benötigt. Dazu kommt die Fehlerbehandlung, die festlegt, was bei einem fehlgeschlagenen Schritt geschieht. Und schließlich gibt es den Zustand, also die Zwischenergebnisse, die der Ablauf bis zu seinem Ende mitführt.

Unter diesen Bausteinen ist der Datenfluss der unauffälligste und zugleich fehleranfälligste. Jeder Schritt liefert Ergebnisse, die ein späterer Schritt benötigt, und diese Übergaben müssen explizit beschrieben sein. Im Bestellbeispiel braucht der Versand die Reservierungs-ID aus dem ersten Schritt. Bleibt diese Verbindung implizit, funktioniert der Ablauf nur zufällig, solange die Reihenfolge stimmt, und bricht, sobald jemand sie umstellt. Eine gute Orchestrierung macht jede Datenübergabe sichtbar, sodass die Abhängigkeiten zwischen den Schritten klar benannt sind.

Diese Bausteine lassen sich auf zwei Wegen umsetzen. Der erste ist Code. Ein Service enthält die Reihenfolge als Programmlogik, ruft die anderen nacheinander auf und behandelt Fehler mit den Mitteln der Programmiersprache. Der zweite Weg ist eine deklarative Beschreibung, die den Ablauf als Daten festhält und nicht als Programmcode. Genau dafür gibt es seit 2024 mit Arazzo eine eigene Spezifikation der OpenAPI Initiative. Was Arazzo ist und wie es Workflows beschreibt, behandelt der Artikel Was ist Arazzo.

Das Beispiel zeigt den Bestellablauf als Abfolge von Schritten. Der Versand erhält die Reservierungs-ID aus dem ersten Schritt, und die Reihenfolge liegt fest. Ob ein Team diesen Ablauf als Code oder als deklarative Spec umsetzt, hängt von der Situation ab. Code bleibt flexibler, eine Spec ist leichter zu prüfen, zu dokumentieren und für Werkzeuge wie Testrunner oder KI-Agenten nutzbar.

Ein fünfter Baustein wird oft erst im Betrieb wichtig, nämlich die Observability. Ein orchestrierter Ablauf besteht aus mehreren Aufrufen, und im Fehlerfall muss nachvollziehbar sein, an welchem Schritt ein Vorgang hängengeblieben ist. Eine durchgehende Correlation-ID, die jeden Aufruf eines Vorgangs markiert, macht den Weg durch die beteiligten Services sichtbar. Ohne diese Klammer zerfällt ein Vorgang in einzelne, scheinbar unzusammenhängende Aufrufe in verschiedenen Log-Dateien. Gerade weil Orchestrierung mehrere Systeme berührt, gehört die Überwachung von Anfang an in den Entwurf und nicht erst in die spätere Fehlersuche.

Fehler, Wiederholung und Kompensation

Der schwierigste Teil einer Orchestrierung ist selten der Erfolgsfall. Gelingt jeder Schritt, ist die Reihenfolge schnell programmiert. Interessant wird es, sobald ein Schritt in der Mitte fehlschlägt. Im Bestellbeispiel ist der Lagerbestand bereits reserviert und die Zahlung autorisiert, doch der Versand lässt sich nicht anlegen. Der Vorgang darf jetzt weder einfach abbrechen noch unverändert weiterlaufen.

Hier kommen zwei Mechanismen ins Spiel. Der erste ist die Wiederholung. Viele Fehler sind vorübergehend, etwa ein kurzzeitig nicht erreichbarer Dienst. Eine Orchestrierung wiederholt einen solchen Schritt nach einer kurzen Wartezeit, bevor sie ihn als endgültig gescheitert behandelt. Damit eine Wiederholung gefahrlos möglich ist, muss der Aufruf idempotent sein. Ein zweimal ausgeführter Schritt darf weder zu einer doppelten Reservierung noch zu einer doppelten Zahlung führen.

Der zweite Mechanismus ist die Kompensation. Lässt sich ein Schritt endgültig nicht ausführen, müssen die bereits erledigten Schritte rückgängig gemacht werden. Die reservierte Ware wird freigegeben, die autorisierte Zahlung storniert. Dieses Muster, bei dem jeder Schritt eine zugehörige Ausgleichsaktion kennt, ist als Saga bekannt. Eine Orchestrierung kennt die Reihenfolge der Schritte und damit auch die Reihenfolge, in der sie im Fehlerfall zurückgenommen werden.

Die Kompensation hat allerdings Grenzen. Manche Aktionen lassen sich nicht sauber zurücknehmen. Eine bereits versendete Benachrichtigung erreicht den Empfänger, eine ausgelöste Auszahlung ist angekommen. Für solche Schritte gibt es zwei übliche Antworten. Entweder wird die nicht umkehrbare Aktion möglichst spät im Ablauf platziert, wenn alle riskanten Schritte bereits gelungen sind, oder es wird eine fachliche Ausgleichsaktion definiert, etwa eine Rückbuchung, die den ursprünglichen Effekt aufhebt. Welcher Weg passt, ist eine fachliche Entscheidung und keine rein technische.

Kurze und langlaufende Abläufe

Nicht jede Orchestrierung läuft in Millisekunden ab. Es lohnt sich, zwei Arten von Abläufen zu unterscheiden, weil sie unterschiedliche Anforderungen an die steuernde Schicht stellen.

Kurze Abläufe sind innerhalb eines einzigen Aufrufs abgeschlossen. Die Bestellung prüft den Bestand, autorisiert die Zahlung und stößt den Versand an, alles in wenigen Sekunden. Die Orchestrierung hält den Zustand nur für die Dauer dieses einen Vorgangs im Speicher. Schlägt etwas fehl, ist der gesamte Ablauf noch präsent und lässt sich sauber zurückrollen.

Langlaufende Abläufe ziehen sich dagegen über Minuten, Stunden oder Tage. Ein Genehmigungsprozess wartet auf die Freigabe durch einen Menschen, eine Provisionierung auf die Rückmeldung eines externen Systems. Hier reicht der Speicher nicht aus. Die Orchestrierung muss ihren Zustand dauerhaft ablegen, damit ein Ablauf einen Neustart der steuernden Anwendung übersteht. Genau an dieser Stelle wird sichtbar, warum Orchestrierung eine eigene Schicht verdient. Den Zustand eines tagelangen Vorgangs nebenbei in einem fachlichen Service zu halten, überlastet diesen Dienst schnell.

Mit der Dauer steigt auch die Bedeutung von Zeitgrenzen. Ein Schritt, der auf eine externe Rückmeldung wartet, braucht eine Obergrenze, ab der der Vorgang als nicht erfolgreich gilt und in einen definierten Zustand übergeht. Ohne eine solche Grenze sammeln sich Vorgänge an, die unbemerkt für immer warten und Ressourcen binden.

Die neue AsyncAPI-Unterstützung von Arazzo zielt auf genau solche Abläufe, weil sie Schritte beschreibt, die auf ein Ereignis warten. Was Version 1.1.0 dazu mitbringt, behandelt der Artikel Was ist neu in Arazzo 1.1.

Orchestrierung als Code oder als Spezifikation

Bleibt die Frage, in welcher Form ein Ablauf festgehalten wird, als Programmcode oder als deklarative Spezifikation. Sie wird gern wie eine Glaubensfrage behandelt, dabei ist sie eine Abwägung im Einzelfall.

Code spielt seine Stärke aus, wenn ein Ablauf viel bedingte Logik enthält, die sich schwer in eine Beschreibung pressen lässt. Verzweigungen, Schleifen und aufwendige Berechnungen sind in einer Programmiersprache natürlicher ausgedrückt. Der Preis dafür ist, dass die Reihenfolge im Code verteilt liegt und sich nur durch Lesen des Programms erschließt.

Eine deklarative Spezifikation kehrt dieses Verhältnis um. Der gesamte Ablauf liegt als Datei an einer Stelle und lässt sich ohne Programmierkenntnisse lesen. Ein Werkzeug kann die Beschreibung prüfen, daraus Tests ableiten oder sie einem KI-Agenten als Bauplan geben. Diese Vorteile zahlen sich vor allem bei Abläufen aus, die stabil sind und über mehrere Teams hinweg verstanden werden müssen. Für hochdynamische Logik mit vielen Sonderfällen bleibt Code die bessere Wahl.

In der Praxis verläuft die Grenze oft mitten durch einen Vorgang. Die grobe Reihenfolge der Schritte wird deklarativ beschrieben, während einzelne Schritte intern weiterhin eigene Code-Logik enthalten. Wie ein solcher Ablauf konkret als Spec entsteht, zeigt Schritt für Schritt die Anleitung Arazzo in der Praxis.

Wann sich Orchestrierung lohnt und wann nicht

Nicht jeder Ablauf braucht eine eigene Orchestrierungs-Schicht. Bei der Entscheidung helfen drei Fragen.

1. Hängen die Schritte wirklich voneinander ab? Wenn ein späterer Aufruf das Ergebnis eines früheren benötigt, spricht das für Orchestrierung. Sind die Aufrufe unabhängig, genügt oft ein paralleler Aufruf ohne zentrale Steuerung.
2. Muss die Reihenfolge verlässlich feststehen? Bei einem Bezahlvorgang ist die Reihenfolge fachlich zwingend. Bei lose gekoppelten Benachrichtigungen darf sie variieren, und dann passt eher Choreographie.
3. Wird derselbe Ablauf an mehreren Stellen ausgelöst? Wenn Web, App und Partner-Schnittstelle denselben Vorgang anstoßen, lohnt sich eine zentrale Beschreibung, damit die Logik nicht dreifach getrennt gepflegt wird.

Gegen eine eigene Schicht spricht, wenn ein Ablauf nur aus einem einzigen Aufruf besteht oder wenn die Schritte unabhängig voneinander sind. In diesen Fällen erzeugt eine zusätzliche Schicht mehr Aufwand, als sie einspart. Orchestrierung lohnt sich dort, wo die Koordination ohnehin stattfindet, heute aber unsichtbar in einem Service liegt.

Ein einfacher Anhaltspunkt ist die Zahl drei. Ein Vorgang aus zwei voneinander abhängigen Aufrufen lässt sich oftmals noch sauber im aufrufenden Code halten. Ab drei Schritten mit Datenübergaben und eigener Fehlerlogik wächst der Nutzen einer expliziten Beschreibung deutlich. Die Grenze ist kein fester Wert, sie markiert eher, ab wann sich das Gespräch über eine eigene Orchestrierung lohnt.

Häufige Fehler bei der Orchestrierung

Aus Architektur-Reviews orchestrierter Abläufe kennen wir eine Reihe typischer Auffälligkeiten. Die fünf häufigsten wollen wir hier einmal benennen.

1. Die versteckte Orchestrierung. Ein fachlicher Service ruft nach und nach immer mehr andere auf, bis er unbemerkt zur zentralen Steuerung wird. Die Logik ist vorhanden, aber niemand hat sie als Orchestrierung benannt oder verantwortet.
2. Die überladene Schicht. Die Orchestrierung übernimmt mit der Zeit fachliche Aufgaben, die in die einzelnen Services gehören. Aus der dünnen Steuerungsschicht wird so ein neuer Monolith, der das ursprüngliche Problem wiederholt.
3. Die fehlende Idempotenz. Schritte lassen sich nicht gefahrlos wiederholen, weil ein zweiter Aufruf einen zweiten Effekt auslöst. Sobald ein Netzwerkfehler eine Wiederholung erzwingt, entstehen doppelte Buchungen oder Reservierungen.
4. Der blinde Fleck bei Fehlern. Der Erfolgsfall ist sauber gebaut, der Fehlerfall nur grob. Ein in der Mitte abgebrochener Ablauf hinterlässt dann einen Zustand, den niemand mehr eindeutig auflösen kann.
5. Das fehlende Monitoring. Der Ablauf läuft, aber im Fehlerfall fehlt die durchgehende Spur. Ohne eine gemeinsame Correlation-ID lässt sich kaum rekonstruieren, an welchem Schritt ein Vorgang gescheitert ist.

Diese Muster haben eine Gemeinsamkeit. Hinter ihnen steckt meist keine falsche Entscheidung. Es wurde schlicht gar keine getroffen. Orchestrierung wächst schleichend, und genau deshalb lohnt es sich, sie früh bewusst zu benennen.

Orchestrierung und KI-Agenten

Ein neuer Treiber für das Thema sind KI-Agenten. Ein Agent, der eine Bestellung bearbeiten soll, steht vor genau der Frage, die auch ein klassischer Orchestrierer beantwortet. In welcher Reihenfolge ruft er die beteiligten Services auf, und wie reagiert er, wenn ein Schritt fehlschlägt?

Hier treffen zwei Ansätze aufeinander. Ein Agentic Workflow lässt das Sprachmodell zur Laufzeit selbst entscheiden, welcher Schritt als Nächstes kommt. Das ist stark, wenn der Ablauf wirklich variabel ist. Für einen Bezahlvorgang, dessen Reihenfolge feststeht, ist diese Freiheit jedoch ein Risiko. Eine deklarative Orchestrierung gibt dem Agenten einen festen Bauplan, den er ausführt, ohne die Reihenfolge selbst erfinden zu müssen. Die Arbeit an AI-Ready APIs und an Orchestrierungs-Beschreibungen verfolgt dasselbe Ziel, nämlich Abläufe so festzuhalten, dass auch maschinelle Konsumenten sie zuverlässig ausführen.

In der Praxis kombinieren viele Teams beide Richtungen. Ein Agent übernimmt die Teile eines Vorgangs, die echtes Urteilsvermögen verlangen, etwa die Bewertung eines Sonderfalls, und stützt sich für den festen Kern des Ablaufs auf eine deklarative Beschreibung. Die Orchestrierung gibt dabei den verlässlichen Rahmen vor, innerhalb dessen der Agent entscheidet. So bleibt die Reihenfolge dort fest, wo sie fest sein muss, und beweglich dort, wo Spielraum einen Mehrwert bringt.

Was das für Teams bedeutet

Sobald Orchestrierung als eigene Schicht sichtbar wird, stellt sich eine organisatorische Frage. Wem gehört der Ablauf? Die einzelnen Services haben klare Eigentümer, der Vorgang darüber oftmals nicht. Solange die Orchestrierung in einem fachlichen Service versteckt ist, trägt dessen Team die Verantwortung mit, ohne sie je benannt zu haben.

Eine explizite Orchestrierungs-Beschreibung macht diese Verantwortung sichtbar. Der Ablauf bekommt einen Ort, einen Eigentümer und eine eigene Versionierung. Das ist zunächst mehr Aufwand, zahlt sich aber dort aus, wo ein Vorgang über mehrere Team-Grenzen hinweg läuft. Damit ein solcher Ablauf auffindbar bleibt, gehört er in denselben Katalog wie die beteiligten APIs, ein Thema, das der Artikel API-Katalog in großen Organisationen vertieft.

Hilfreich ist es, den Ablauf wie eine eigene API zu behandeln. Er bekommt einen Namen, eine Beschreibung und eine Version, und Änderungen an ihm werden bewusst entschieden und nicht nebenbei im Code eines einzelnen Teams getroffen. Damit wird aus einer impliziten Abhängigkeit zwischen mehreren Services ein benanntes Artefakt, über das Teams sprechen und das sie gemeinsam weiterentwickeln können.

So kommen Sie in die Umsetzung

Der Einstieg in das Thema beginnt mit einer Bestandsaufnahme und nicht mit einem Werkzeug. Nehmen Sie einen Geschäftsvorgang, der heute über mehrere Services läuft, zeichnen Sie die Reihenfolge der Aufrufe einmal vollständig auf und prüfen Sie, in welchem Service die Steuerung aktuell unausgesprochen liegt. Diese eine Skizze beantwortet meist schon, ob Ihre Architektur eine explizite Orchestrierung braucht und wo sie ansetzen muss.

Wenn Sie für diese Bestandsaufnahme einen erfahrenen Blick von außen wollen, setzen unsere Professional API Services genau dort an. Wir analysieren gewachsene API-Landschaften, machen versteckte Orchestrierungen sichtbar und erarbeiten gemeinsam mit Ihrem Team den tragfähigen Schnitt zwischen fachlicher Arbeit und Ablauf-Steuerung.