Orchestrierung vs. Choreographie

Für die Verbindung mehrerer Services zu einem Ablauf gibt es zwei Lager. Das eine setzt auf einen zentralen Orchestrierer, der Bestand, Zahlung und Versand nacheinander aufruft. Das andere will genau diese zentrale Instanz vermeiden und lässt jeden Service auf Events reagieren. Beide haben gute Argumente, und genau das macht die Entscheidung schwer.

Hinter den beiden Lagern stehen die zwei Grundmodelle, mit denen sich mehrere Services zu einem Ablauf verbinden lassen. Orchestrierung setzt auf eine steuernde Instanz, Choreographie auf verteilte Reaktionen. Welches Modell passt, hängt weniger von Vorlieben ab als von den Eigenschaften des konkreten Ablaufs. Genau diese Eigenschaften lohnt es sich anzusehen, bevor die Entscheidung fällt.

Zwei Modelle für dasselbe Problem

Beide Ansätze beantworten dieselbe Frage, nämlich wie aus einzelnen Services ein zusammenhängender Geschäftsvorgang wird. Dabei geben sie entgegengesetzte Antworten auf die Frage, wo das Wissen über den Ablauf liegt.

Bei der Orchestrierung liegt dieses Wissen an einer Stelle. Ein Orchestrierer kennt die Schritte, ihre Reihenfolge und die Datenübergaben dazwischen. Er ruft den Lager-Service auf, wartet auf das Ergebnis, ruft danach die Zahlung auf und zum Schluss den Versand. Die beteiligten Services wissen nichts voneinander. Sie beantworten Anfragen, mehr nicht. Der Ablauf selbst ist ein eigenes Artefakt, das sich lesen, versionieren und ändern lässt, ohne die Services anzufassen. Wie eine solche Steuerung grundsätzlich aufgebaut ist, beschreibt der Überblick zur API-Orchestrierung.

Bei der Choreographie ist das Wissen verteilt. Es gibt keinen Ort, an dem der Ablauf vollständig beschrieben steht. Stattdessen veröffentlicht der Bestell-Service ein Event, sobald eine Bestellung eingeht. Der Lager-Service hört auf dieses Event und reserviert die Ware. Sobald die Reservierung steht, veröffentlicht er selbst ein Event, auf das der Zahlungs-Service reagiert. Jeder Dienst kennt nur die Events, die ihn betreffen. Der Gesamtablauf ergibt sich aus dem Zusammenspiel der einzelnen Reaktionen, ohne dass eine zentrale Instanz den Takt vorgibt.

Wie sich die Kopplung unterscheidet

Der auffälligste Unterschied betrifft die Abhängigkeiten zwischen den Beteiligten. Ein Orchestrierer muss jeden Service kennen, den er aufruft, mitsamt dessen API und Fehlerverhalten. Die Services selbst bleiben dafür frei von Wissen über den Ablauf. Diese Kopplung ist sichtbar und konzentriert. Wer den Orchestrierer liest, sieht alle Abhängigkeiten auf einen Blick.

Die Choreographie dreht das um. Kein Service kennt die anderen direkt, alle kennen nur den Event-Kanal. Ein neuer Konsument kann auf ein bestehendes Event hören, ohne dass der Sender davon erfährt oder angepasst werden muss. Diese lose Kopplung ist das stärkste Argument für die Choreographie. Sie hat allerdings eine Kehrseite, die im Alltag oft erst spät auffällt. Die Abhängigkeiten verschwinden nicht, sie werden unsichtbar. Welche Services auf ein Event reagieren und was eine Änderung am Event-Schema auslöst, steht nirgendwo zentral beschrieben.

Das Event-Schema wird zum Vertrag

In der Choreographie übernimmt das Event-Schema die Rolle, die in der Orchestrierung die API des Orchestrierers spielt. Es ist der Vertrag, auf den sich alle Beteiligten verlassen. Ein Beispiel zeigt, wie viel ein solches Event tragen muss.

{
  "eventType": "order.placed",
  "eventId": "b7c2…",
  "occurredAt": "2026-06-12T09:14:00Z",
  "correlationId": "order-4711",
  "payload": {
    "orderId": "4711",
    "customerId": "8842",
    "items": [ { "sku": "A-100", "quantity": 2 } ]
  }
}

Drei Felder verdienen Aufmerksamkeit. Die correlationId verbindet alle Events eines Vorgangs und ist die Voraussetzung dafür, den Gesamtablauf später überhaupt rekonstruieren zu können. Der eventType mit Versionsbezug entscheidet darüber, wie sich das Schema weiterentwickeln lässt, ohne elf unbekannte Konsumenten zu brechen. Und die eventId erlaubt es Konsumenten, doppelt zugestellte Events zu erkennen, denn die meisten Event-Infrastrukturen garantieren eine mindestens einmalige Zustellung und keine genau einmalige.

Wer diese Felder erst nachrüstet, wenn der erste Produktionsvorfall sie verlangt, zahlt deutlich mehr als bei einem sauberen Start. Insofern relativiert sich der gefühlte Vorsprung der Choreographie beim Einstieg. Die zentrale Komponente entfällt, dafür wandert der Designaufwand in das Event-Schema und seine Versionierung.

Latenz, Durchsatz und der Betrieb

Im Betrieb unterscheiden sich die Modelle weniger dramatisch, als die Diskussion oft vermuten lässt, aber an zwei Stellen spürbar. Eine Orchestrierung arbeitet meist mit synchronen Aufrufen und liefert dadurch ein direktes Ende des Vorgangs. Der Aufrufer erfährt innerhalb einer Antwortzeit, ob die Bestellung steht. Dafür hängt der Durchsatz an der langsamsten beteiligten API, und der Orchestrierer selbst muss für Lastspitzen ausgelegt sein.

Eine Choreographie entkoppelt die Last über den Event-Kanal. Lastspitzen laufen in Queues, jeder Konsument arbeitet in seinem Tempo, und ein langsamer Dienst bremst die anderen nicht aus. Der Preis ist die fehlende unmittelbare Antwort. Der Aufrufer erhält zunächst nur die Bestätigung, dass sein Auftrag angenommen wurde, und der tatsächliche Abschluss kommt später. Für viele Vorgänge ist das fachlich völlig in Ordnung, für manche schlicht nicht. Auch diese Frage gehört in die Analyse, bevor das Modell feststeht.

Der Weg von einem Modell zum anderen

Beruhigend ist, dass die Entscheidung kein Einbahnweg ist. Der häufigste Wechsel in der Praxis führt von der gewachsenen Choreographie zur expliziten Orchestrierung, und er beginnt fast immer mit demselben Symptom. Irgendwo entsteht eine Komponente, die hängende Vorgänge überwacht. Wer diesen Punkt erreicht, zieht die Ablauf-Logik am besten vollständig in einen benannten Orchestrierer um, statt die Überwachung weiter auszubauen, denn eine halbe Steuerung vereint die Nachteile beider Modelle.

Der umgekehrte Weg ist seltener, aber einfacher. Aus einem orchestrierten Ablauf werden einzelne Schritte herausgelöst und als Event-Reaktionen nachgelagert, üblicherweise die, die mit dem Erfolg des Vorgangs nichts zu tun haben. Der Orchestrierer wird dadurch kleiner und konzentriert sich auf den verbindlichen Kern. Beide Wege funktionieren schrittweise, ein großer Umbau in einem Zug ist selten nötig.

Konsistenz und Fehlerfälle

Der Vergleich wird erst beim Scheitern richtig interessant. Im Erfolgsfall funktionieren beide Modelle ordentlich. Der Unterschied zeigt sich, wenn ein Schritt in der Mitte fehlschlägt und bereits erledigte Schritte zurückgenommen werden müssen.

Hier hat es eine Orchestrierung vergleichsweise leicht. Der Orchestrierer kennt den Stand des Ablaufs und weiß, welche Schritte bereits gelungen sind. Schlägt der Versand fehl, stößt er die Stornierung der Zahlung und die Freigabe der Reservierung an, in genau dieser Reihenfolge. Das Saga-Muster mit seinen Ausgleichsaktionen lässt sich zentral umsetzen, weil eine Stelle den Überblick hat.

In einer Choreographie muss dieselbe Logik verteilt gebaut werden. Der Versand-Service veröffentlicht ein Fehler-Event, auf das der Zahlungs-Service mit einer Stornierung reagiert, die wiederum ein Event auslöst, auf das der Lager-Service antwortet. Jeder Kompensationspfad ist eine eigene Event-Kette. Das funktioniert, verlangt aber deutlich mehr Disziplin, weil der Fehlerpfad genauso sorgfältig choreographiert werden muss wie der Erfolgspfad. In der Praxis wird genau dieser Teil gern aufgeschoben, und dann hinterlässt der erste ernsthafte Ausfall einen halbfertigen Zustand, den niemand mehr eindeutig auflösen kann.

Observability und der Blick auf den Gesamtablauf

Eng verwandt mit der Fehlerfrage ist die Observability. Ein orchestrierter Ablauf hat einen natürlichen Ort, an dem sein Zustand sichtbar ist. Der Orchestrierer weiß, welcher Vorgang an welchem Schritt steht, wie lange er dort schon wartet und woran ein abgebrochener Lauf gescheitert ist. Dashboards und Auswertungen entstehen fast nebenbei.

Eine Choreographie hat diesen Ort nicht. Der Zustand eines Vorgangs ergibt sich aus Events, die über mehrere Topics und Services verteilt sind. Um die Frage zu beantworten, wo Bestellung 4711 gerade steht, müssen Events korreliert werden, üblicherweise über eine gemeinsame Correlation-ID und ein eigenes Tracing über den Event-Fluss hinweg. Das ist lösbar und in reifen Event-Architekturen auch gelöst, aber es ist Arbeit, die bei der Orchestrierung schlicht nicht anfällt. Teams unterschätzen diesen Posten gern, weil er in der Entwurfsphase unsichtbar bleibt und erst im Betrieb Gewicht bekommt.

Dazu kommt ein subtiler Punkt, der selten ausgesprochen wird. In einer Choreographie lässt sich schwer beweisen, dass ein Ablauf vollständig ist. Ob auf ein Event tatsächlich alle vorgesehenen Reaktionen erfolgt sind, sieht man dem System nicht an. Eine Orchestrierung kennt dagegen die Erwartung, gegen die jeder Lauf geprüft werden kann.

Tempo der Veränderung und Team-Schnitt

Bei der Frage, wie sich ein System weiterentwickelt, sammelt die Choreographie Punkte. Ein neues Team kann einen zusätzlichen Konsumenten an ein bestehendes Event hängen, ohne mit dem Sender-Team auch nur zu sprechen. Für Organisationen mit vielen autonomen Teams ist das ein echter Geschwindigkeitsvorteil. Niemand wartet auf ein zentrales Gremium, das den Ablauf ändert.

Die Orchestrierung verlangt an dieser Stelle Koordination. Wer einen Schritt in den Ablauf einfügen will, ändert den Orchestrierer, und der hat einen Eigentümer, mit dem die Änderung abzustimmen ist. Das bremst, schafft aber zugleich einen Ort, an dem über den Ablauf entschieden wird. Ob das eine Stärke oder eine Schwäche ist, hängt davon ab, wie geschäftskritisch der Vorgang ist. Bei einem Bezahlprozess ist die bewusste Entscheidung an einer Stelle meist erwünscht. Bei einem Benachrichtigungs-Strom, an den laufend neue Konsumenten andocken, wäre sie reine Bürokratie.

Die Kriterien im Überblick

Aus diesen Unterschieden lässt sich eine kompakte Entscheidungsmatrix ableiten.

Die Tabelle zeigt ein Muster. Orchestrierung gewinnt überall dort, wo Verbindlichkeit zählt, also bei Reihenfolge, Fehlerbehandlung und Nachvollziehbarkeit. Choreographie gewinnt dort, wo Unabhängigkeit zählt, also bei Kopplung und Änderungstempo. Es gibt keinen Gewinner über alle Kriterien, und genau deshalb existieren beide Modelle seit Jahren nebeneinander.

Wann welcher Ansatz passt

Aus der Matrix ergeben sich Faustregeln, die sich in Projekten bewährt haben.

• Orchestrierung passt, wenn die Reihenfolge fachlich zwingend ist, der Vorgang ein klares Ende hat und im Fehlerfall ein definierter Zustand erreicht werden muss. Ein Bezahlvorgang, ein Partner-Onboarding oder eine Buchung sind typische Kandidaten.
• Choreographie passt, wenn viele Konsumenten unabhängig auf dasselbe Ereignis reagieren und keiner von ihnen für den Erfolg des Gesamtvorgangs verantwortlich ist. Eine Bestellbestätigung, auf die Mail-Versand, Statistik und Empfehlungssystem gleichzeitig reagieren, ist der klassische Fall.
• Die Zahl der Schritte gibt einen Hinweis. Lange Ketten mit fünf oder mehr abhängigen Schritten werden als Choreographie schnell unübersichtlich, weil sich die Kette durch kein einzelnes Dokument mehr nachvollziehen lässt.
• Auch die Frage nach dem Eigentümer hilft. Wenn ein konkretes Team für den Gesamtvorgang geradestehen muss, braucht dieses Team auch die Kontrolle, und das spricht für Orchestrierung.

Eine Beobachtung dazu, die sich über Jahre wiederholt. Teams wählen Choreographie häufig weniger wegen der fachlichen Eigenschaften des Ablaufs als aus Scheu vor der zentralen Komponente, die nach Engpass klingt. Einige Monate später bauen sie dann doch eine Stelle, die den Event-Fluss überwacht, Timeouts anstößt und hängende Vorgänge weiterschiebt. Das ist dann ein Orchestrierer, er heißt nur anders. Umgekehrt gibt es Orchestrierer, die zu Event-Verteilern degenerieren, weil niemand die Reihenfolge wirklich braucht. Beide Fehlformen entstehen, wenn das Modell vor der Analyse des Ablaufs gewählt wird.

Mischformen sind der Normalfall

Die Diskussion wird oft geführt, als müsste sich eine Architektur für eines der beiden Modelle entscheiden. Reale Systeme tun das selten. Sie orchestrieren die Vorgänge, die Verbindlichkeit brauchen, und choreographieren die Ströme, die Unabhängigkeit brauchen, beides im selben System.

Das Bestellbeispiel zeigt die Kombination. Der Kernablauf aus Reservierung, Zahlung und Versand läuft orchestriert, weil Reihenfolge und Kompensation verbindlich sein müssen. Sobald die Bestellung abgeschlossen ist, veröffentlicht der Orchestrierer ein einziges Event. Auf dieses Event reagieren Mail-Versand, Statistik, Empfehlungssystem und Archivierung choreographiert, weil keiner dieser Konsumenten den Kernablauf beeinflusst. Die Grenze verläuft genau dort, wo die Verbindlichkeit endet.

Inzwischen folgen auch deklarative Workflow-Beschreibungen dieser Linie. Arazzo, die Workflow-Spezifikation der OpenAPI Initiative, beschreibt orchestrierte Abläufe, kann seit Version 1.1.0 aber auch Schritte abbilden, die auf Events warten. Die Grenze zwischen den Modellen wird damit auch in der Spec-Welt durchlässiger. Was Arazzo grundsätzlich leistet, erklärt der Artikel Was ist Arazzo, die Event-Erweiterungen behandelt Was ist neu in Arazzo 1.1.

Die Entscheidung in der Praxis

Zurück zu den beiden Lagern. In der Praxis läuft die Auflösung meist darauf hinaus, den Bestellprozess zu orchestrieren und die nachgelagerten Reaktionen zu choreographieren, beide Ansätze also umzusetzen, jeden an der Stelle, an der seine Stärken liegen. Die Diskussion fällt deutlich kürzer aus, wenn die Frage von Anfang an „welche Teile dieses Ablaufs brauchen Verbindlichkeit und welche brauchen Unabhängigkeit" lautet und nicht „welches Modell ist besser".

Zwei verwandte Abgrenzungen runden das Bild ab. Wie sich die Orchestrierung vom API-Gateway unterscheidet, das oft fälschlich für dieselbe Schicht gehalten wird, klärt API-Orchestrierung vs. API-Gateway. Und wo die Grenzen zu Composition und Aggregation verlaufen, zeigt Composition.

Nehmen Sie sich einen Ablauf vor, der in Ihrem System heute über Events läuft, und prüfen Sie, ob irgendwo bereits eine Komponente Timeouts überwacht oder hängende Vorgänge weiterschiebt. Wenn ja, haben Sie Ihren versteckten Orchestrierer gefunden, und es lohnt sich, ihn explizit zu machen.