Composition, Orchestration, Aggregation

Wer zu diesen drei Begriffen recherchiert, macht eine eigentümliche Erfahrung. Die Suche nach API-Composition liefert Artikel, die von Orchestration handeln. Die Suche nach Aggregation liefert Texte, die beides munter mischen. Und in mancher Hersteller-Dokumentation bezeichnet dasselbe Wort je nach Kapitel zwei verschiedene Funktionen. Die Verwirrung liegt also weniger bei den Lesern als im Schrifttum selbst, das die drei Begriffe seit Jahren synonym behandelt, obwohl sie unterschiedliche Muster beschreiben.

Dabei ist die Unterscheidung keine akademische Übung. Hinter jedem der drei Begriffe steht ein eigenes Muster mit eigenen Anforderungen an Zustand, Fehlerbehandlung und Team-Zuständigkeit. Wer einen Anwendungsfall dem falschen Muster zuordnet, baut entweder zu viel, weil eine simple Datenbündelung plötzlich Kompensations-Logik bekommt, oder zu wenig, weil ein schreibender Ablauf wie eine Leseanfrage behandelt wird und im Fehlerfall halbe Zustände hinterlässt.

Der Überblick vor dem Detail

Bevor die drei Muster einzeln zur Sprache kommen, hilft ein grober Überblick. Alle drei koordinieren mehrere API-Aufrufe, und genau diese Gemeinsamkeit stiftet die Verwirrung. Die Unterschiede stecken in drei Fragen. Werden Daten verändert oder nur gelesen? Hängen die Aufrufe voneinander ab oder sind sie unabhängig? Und muss im Fehlerfall etwas zurückgenommen werden?

Schon dieser Überblick beantwortet die meisten Zuordnungsfragen. Für alles Weitere lohnt der Blick auf die Muster im Einzelnen, jeweils mit einem Beispiel aus derselben fachlichen Welt, damit die Unterschiede direkt vergleichbar bleiben.

Woher die Begriffe stammen

Ein Teil der Verwirrung erklärt sich aus der Herkunft der drei Wörter, denn sie stammen aus verschiedenen Epochen und Communities. Orchestration ist der älteste der drei Begriffe im API-Umfeld. Er kommt aus der SOA-Welt der 2000er-Jahre, in der Geschäftsprozesse über BPEL und zentrale Prozess-Engines gesteuert wurden. Mit diesem Erbe trägt das Wort bis heute den Beigeschmack schwergewichtiger Middleware, was die Diskussion oft emotionaler macht, als die Sache verlangt.

Composition wurde von der Microservices-Literatur geprägt, dort allerdings ziemlich präzise als Abfrage-Muster über verteilte Datenbestände, als Gegenstück zum verteilten Join, den es in einer Welt eigenständiger Service-Datenbanken nicht mehr gibt. Erst der spätere, lockere Gebrauch hat das Wort zur Sammelbezeichnung für jedes Zusammensetzen von APIs verwässert.

Aggregation schließlich stammt aus dem Gateway-Umfeld und bezeichnete dort von Anfang an eine Produktfunktion, nämlich das Bündeln mehrerer Backend-Antworten in einer Response. Drei Communities, drei Jahrzehnte, drei Bedeutungen, und weil alle drei Muster oberflächlich dasselbe tun, nämlich mehrere Aufrufe zusammenfassen, wanderten die Wörter irgendwann frei zwischen den Bedeutungen hin und her.

Aggregation, die Datenbündelung

Das einfachste der drei Muster ist die Aggregation. Ein Aufruf sammelt Ergebnisse mehrerer unabhängiger Quellen ein und gibt sie gebündelt zurück. Das klassische Beispiel ist die Startseite einer Kunden-App. Sie zeigt den Namen des Kunden, seine letzten drei Bestellungen und den Status seiner Support-Tickets. Drei Services, drei Aufrufe, eine Antwort.

Entscheidend ist, was hier alles fehlt. Es gibt keine Reihenfolge, die Aufrufe können parallel laufen. Es gibt keinen Datenfluss zwischen den Aufrufen, keiner braucht das Ergebnis eines anderen. Und es gibt nichts zu kompensieren, weil nichts verändert wird. Fällt eine Quelle aus, fehlt schlicht ein Kasten auf der Startseite, und viele Implementierungen liefern dann bewusst eine Teilantwort statt eines Fehlers.

Wegen dieser Anspruchslosigkeit darf Aggregation an Orten leben, die für echte Abläufe tabu sind. Ein API-Gateway kann sie übernehmen, ein Backend-for-Frontend ebenso. Die Grenze dafür beschreibt der Vergleich Orchestrierung vs. API-Gateway genauer, und sie verläuft exakt beim ersten schreibenden Schritt.

Eine Designfrage bleibt der Aggregation trotz aller Einfachheit, nämlich der Umgang mit unterschiedlichen Antwortzeiten. Wenn zwei Quellen in fünfzig Millisekunden antworten und die dritte in zwei Sekunden, bestimmt die langsamste die Gesamtantwort. Übliche Antworten darauf sind Timeouts pro Quelle mit gekennzeichneten Teilantworten oder ein kurzlebiger Cache für die trägen Quellen. Beides sind Lese-Optimierungen und keine Ablauf-Logik, weshalb sie das Muster nicht verlassen.

Composition, die zusammengesetzte Sicht

Composition ist der Begriff mit der größten Unschärfe im Sprachgebrauch, und er verdient die genaueste Betrachtung. Im engeren Sinn, wie ihn die Microservices-Literatur prägt, bezeichnet API-Composition ein Abfrage-Muster über verteilte Daten. Eine fachliche Frage lässt sich nicht aus einem einzigen Service beantworten, weil die Daten auf mehrere Services verteilt sind, die jeweils ihre eigene Datenbank besitzen.

Das Beispiel aus derselben fachlichen Welt wäre die Frage nach allen offenen Bestellungen eines Kunden samt Lieferstatus und Rechnungssumme. Der Bestell-Service kennt die Bestellungen, der Logistik-Service die Lieferungen, der Rechnungs-Service die Beträge. Ein Composition-Aufruf holt zuerst die Bestellungen, ermittelt aus deren IDs die passenden Lieferungen und Rechnungen und verknüpft alles zu einer Antwort. Anders als bei der Aggregation hängen die Aufrufe hier voneinander ab, denn ohne die Bestell-IDs aus dem ersten Schritt lassen sich die weiteren Abfragen gar nicht stellen.

Trotzdem bleibt Composition ein Lese-Muster. Es verändert nichts, und im Fehlerfall entsteht höchstens eine unvollständige Sicht, kein inkonsistenter Zustand. Die Herausforderungen liegen woanders, nämlich in der Datenmenge, wenn die erste Abfrage tausend Bestellungen liefert, und in der Frage, wie aktuell die zusammengesetzte Sicht sein muss. Bei großen Datenmengen wandert das Muster deshalb oft von der synchronen Abfrage zu einer vorberechneten Sicht, die über Events aktuell gehalten wird, womit die Verwandtschaft zur Choreographie beginnt, die der Vergleich Orchestrierung vs. Choreographie behandelt.

Orchestration, der gesteuerte Ablauf

Das dritte Muster unterscheidet sich kategorisch von den beiden anderen, weil es schreibt. Eine Orchestrierung führt einen fachlichen Vorgang aus, der Daten verändert, und zwar über mehrere Services hinweg in einer verbindlichen Reihenfolge. Im Beispiel der gemeinsamen fachlichen Welt ist das die Bestellung selbst. Der Bestand wird reserviert, die Zahlung autorisiert, der Versand angestoßen, und jeder Schritt baut auf dem Ergebnis des vorherigen auf.

Mit dem Schreiben kommen die Pflichten. Der Ablauf braucht einen Zustand, der festhält, welcher Schritt erledigt ist. Er braucht eine Fehlerbehandlung, die bereits erledigte Schritte zurücknimmt, wenn ein späterer endgültig scheitert. Und er braucht einen Eigentümer, der für den Gesamtvorgang geradesteht. Nichts davon lässt sich wegoptimieren, weil ein abgebrochener Schreibvorgang ohne Kompensation reale Folgen hat, von der blockierten Ware bis zur doppelten Buchung. Die Bausteine im Einzelnen, von Idempotenz über das Saga-Muster bis zu Zeitgrenzen, beschreibt der Überblick zur API-Orchestrierung.

Bemerkenswert ist, wie oft dieses Muster in Verkleidung auftritt. Eine „Aggregation", die am Ende einen Bestätigungs-Datensatz schreibt, ist eine Orchestrierung. Das Gleiche gilt für eine „Composition", die nebenbei einen Cache im Quellsystem aktualisiert. Der erste schreibende Schritt wechselt das Muster, unabhängig davon, wie die Funktion im Code oder im Produktkatalog heißt.

Die Grauzonen, ehrlich benannt

Bei aller Klarheit der Matrix gibt es Zonen, in denen die Zuordnung wirklich Mühe macht, und es wäre unaufrichtig, sie zu verschweigen.

Die erste ist GraphQL. Ein GraphQL-Layer über mehreren Services ist der Form nach Composition, denn er beantwortet Abfragen über verteilte Daten und verknüpft sie anhand von Schlüsseln. Sobald derselbe Layer aber Mutations anbietet, die mehrere Services nacheinander verändern, steckt in ihm eine unausgesprochene Orchestrierung, häufig ohne deren Pflichten. Die Technologie entscheidet also nicht über das Muster, die einzelne Operation tut es.

Die zweite Grauzone sind Batch-Verarbeitungen. Ein nächtlicher Lauf, der zehntausend Datensätze über drei Services schiebt, ist seiner Natur nach eine Orchestrierung in Schleife, wird aber selten so behandelt. Gerade hier zahlt sich die Einordnung aus, weil Wiederholbarkeit und Kompensation bei Massenläufen über die Aufräumarbeit nach einem Abbruch entscheiden.

Die dritte Zone ist die vorberechnete Lese-Sicht, die per Event aktuell gehalten wird. Sie beantwortet Composition-Fragen, wird aber durch choreographierte Events gefüllt. Für die Zuordnung hilft die Trennung in zwei Teile. Das Befüllen ist Event-Verarbeitung, das Abfragen ist eine simple Einzelabfrage, und das ursprüngliche Composition-Problem wurde schlicht zur Schreibzeit vorweggenommen.

Die Abgrenzungsmatrix für den Alltag

Für die schnelle Zuordnung im Alltag hat sich eine Matrix mit fünf Prüfkriterien bewährt.

Die Matrix taugt auch als Review-Werkzeug. Wer eine bestehende Funktion einordnen will, geht die fünf Zeilen durch und prüft, ob alle Antworten in derselben Spalte landen. Tun sie das nicht, ist die Funktion meist ein Mischwesen, das stillschweigend ins nächst anspruchsvollere Muster gewachsen ist, ohne dessen Pflichten zu übernehmen.

Wie die drei Muster zusammen auftreten

In einer realen Anwendung treten die Muster selten isoliert auf. Meist bedienen sie verschiedene Stationen, die ein Nutzer nacheinander durchläuft. Das Bestellbeispiel zeigt alle drei innerhalb weniger Minuten Nutzung.

Beim Öffnen der App lädt die Startseite per Aggregation. Kundenname, letzte Bestellungen und Ticket-Status kommen aus drei Services, parallel abgefragt, gebündelt ausgeliefert, und wenn der Ticket-Service gerade lahmt, fehlt eben ein Kasten. Klickt der Kunde auf seine Bestellhistorie mit Lieferstatus und Rechnungsbeträgen, arbeitet dahinter eine Composition, die Bestell-IDs ermittelt und die zugehörigen Daten aus Logistik und Abrechnung verknüpft. Legt er schließlich eine neue Bestellung an, übernimmt die Orchestrierung mit Reservierung, Zahlung und Versand in fester Reihenfolge samt Kompensation für den Fehlerfall.

Drei Stationen, drei Muster, drei völlig unterschiedliche Anforderungsprofile, und doch würde ein flüchtiger Blick auf die Architektur überall dasselbe sehen, nämlich eine Komponente, die mehrere Services aufruft. Genau deshalb lohnt die Begriffspräzision. Sie macht sichtbar, dass die Startseite kein Saga-Muster braucht und die Bestellstrecke sehr wohl, obwohl beide „mehrere APIs zusammenfassen".

Für Teams ergibt sich daraus eine praktische Konsequenz bei der Wiederverwendung. Die Versuchung ist groß, eine einmal gebaute „Zusammenfassungs-Komponente" für alle drei Stationen zu nutzen. Das endet meist in einer Komponente, die für die Startseite zu schwer und für die Bestellstrecke zu leicht ist. Tragfähiger ist es, jeder Station ihr Muster zu lassen und nur die wirklich gemeinsamen Bausteine zu teilen, etwa die Correlation-ID-Weitergabe und das einheitliche Fehlerformat.

Warum die Verwechslung Geld kostet

Man könnte die Begriffsfrage für Wortklauberei halten, solange die Software läuft. Die Kosten der Verwechslung zeigen sich allerdings an drei konkreten Stellen.

1. Falsche Werkzeugwahl. Wer Orchestrierung für Aggregation hält, kauft oder baut eine Workflow-Engine für ein Problem, das ein paralleler Lese-Aufruf gelöst hätte. Wer umgekehrt Aggregation für ausreichend hält, obwohl geschrieben wird, verzichtet auf Kompensation und Zustand, die der Vorgang braucht.
2. Falsche Zuständigkeit. Aggregation darf ein Plattform-Team im Gateway pflegen, ein orchestrierter Geschäftsvorgang gehört dem Fachteam. Die Verwechslung legt fachliche Abläufe in Infrastruktur-Hände oder belastet Fachteams mit Infrastruktur-Pflichten.
3. Falsche Tests. Lese-Muster lassen sich mit einfachen Antwort-Vergleichen testen. Ein schreibender Ablauf braucht Tests für Fehlerpfade, Wiederholungen und Kompensationen. Wer ihn als Lese-Muster einordnet, testet die kritischen Pfade gar nicht erst.

In Architektur-Reviews lohnt es sich deshalb, auf das Wort „einfach" zu hören. Sätze wie „wir aggregieren da einfach drei Aufrufe" verdienen die Nachfrage, ob einer davon schreibt. Erstaunlich oft lautet die Antwort ja, und damit ändert sich die gesamte Anforderungslage.

Drei Muster, eine klare Zuordnung

Die drei Begriffe beschreiben am Ende drei Stufen wachsender Verbindlichkeit. Aggregation bündelt, Composition verknüpft, Orchestration führt aus. Jede Stufe fügt Anforderungen hinzu, von der Abhängigkeit der Aufrufe über den Zustand bis zur Kompensation, und jede Stufe hat ihren eigenen natürlichen Ort in der Architektur.

Wer die Abgrenzung einmal verinnerlicht hat, liest auch das unscharfe Schrifttum entspannter. Hinter einem Artikel über „API-Composition" kann jedes der drei Muster stecken, aber die zwei Prüffragen nach Schreiben und Abhängigkeit ordnen jeden konkreten Fall in wenigen Minuten ein. Nehmen Sie sich die drei meistgenutzten Mehrfach-Aufruf-Funktionen Ihres Systems vor und ordnen Sie sie der Matrix zu. Jede Funktion, deren Antworten nicht in einer Spalte landen, ist ein lohnender Kandidat für das nächste Architektur-Review.