Kaum zwei Bausteine werden so oft verwechselt wie das API-Gateway und die API-Orchestrierung. Beide sitzen zwischen Konsumenten und Services, beide leiten Aufrufe weiter, und in den Produktbroschüren der Hersteller überlappen sich die Versprechen. Der Einwand „wir haben doch ein Gateway, warum brauchen wir jetzt noch eine Orchestrierung?" ist deshalb verständlich und verdient eine begründete Antwort.
Ein Gateway ist eingeführt, die Lizenz bezahlt, und nun steht schon der nächste Architektur-Baustein auf der Liste, der ebenfalls irgendetwas mit dem Verbinden von APIs zu tun hat. Aus Sicht des Fachbereichs klingt das nach demselben Werkzeug in zweiter Ausführung. Tatsächlich beantworten Gateway und Orchestrierung zwei verschiedene Fragen, und keines von beiden übernimmt die Aufgabe des anderen, ohne die eigene zu vernachlässigen.
Ein API-Gateway ist der zentrale Eingangspunkt einer API-Landschaft und übernimmt Querschnittsaufgaben wie Routing, Authentifizierung, Rate Limiting und Logging für einzelne Aufrufe. Eine API-Orchestrierung koordiniert dagegen mehrere Aufrufe zu einem fachlichen Ablauf, inklusive Reihenfolge, Datenübergaben und Fehlerbehandlung. Das Gateway steuert den Datenverkehr, die Orchestrierung steuert Abläufe. Beide ergänzen sich und ersetzen einander nicht.
Was ein API-Gateway leistet
Ein Gateway arbeitet auf der Ebene des einzelnen Aufrufs. Eine Anfrage kommt an, das Gateway prüft das Token, wendet das Rate Limit an, schreibt einen Log-Eintrag und leitet die Anfrage an den zuständigen Service weiter. Die Antwort nimmt denselben Weg zurück. Das alles geschieht pro Request, in Millisekunden, und ohne dass das Gateway versteht, was der Aufruf fachlich bedeutet.
Diese Beschränkung ist kein Mangel, sie ist das Designprinzip. Das Gateway bündelt die Aufgaben, die für alle APIs gleich sind und die kein Team mehrfach bauen sollte. Authentifizierung, Autorisierung, TLS-Terminierung, Rate Limiting, Request-Logging und das Routing auf Basis von Pfaden oder Headern sind solche Querschnittsthemen. Sie gehören an den Rand der Architektur, an eine Stelle, durch die ohnehin jeder Aufruf läuft.
Das Gateway kennt dabei zu keinem Zeitpunkt den Zusammenhang zwischen Aufrufen. Ob die Anfrage an den Zahlungs-Service zur selben Bestellung gehört wie die Anfrage an den Lager-Service zwei Sekunden zuvor, weiß es nicht und muss es auch nicht wissen. Jeder Request ist für das Gateway ein eigenes, abgeschlossenes Ereignis.
Was eine Orchestrierung leistet
Eine Orchestrierung beginnt genau dort, wo das Wissen des Gateways endet, nämlich beim Zusammenhang. Sie kennt den fachlichen Vorgang, der sich über mehrere Aufrufe erstreckt. Im Bestellbeispiel weiß sie, dass zuerst der Bestand reserviert wird, dass die Zahlung das Ergebnis dieser Reservierung braucht und dass der Versand erst starten darf, wenn beides gelungen ist. Sie hält den Zustand des Vorgangs, reicht Daten von Schritt zu Schritt weiter und entscheidet im Fehlerfall, welche Schritte zurückgenommen werden.
Damit arbeitet die Orchestrierung auf einer anderen Zeitskala und mit anderem Wissen. Ein orchestrierter Vorgang kann Sekunden dauern oder Tage, wenn er auf eine Freigabe wartet. Er hat einen Anfang, ein Ende und dazwischen einen Zustand. Auf der Gateway-Ebene existiert nichts davon. Die Grundlagen dieser Ablaufsteuerung beschreibt der Überblick zur API-Orchestrierung, die Abgrenzung zur ereignisgetriebenen Variante behandelt der Vergleich Orchestrierung vs. Choreographie.
Ein Schichtenmodell macht die Grenze sichtbar
Hilfreich ist die Vorstellung von drei Schichten, durch die ein Aufruf wandert. Am Rand sitzt das Gateway und behandelt jeden Request einzeln. Dahinter liegt, wo nötig, die Orchestrierung, die mehrere Requests zu einem Vorgang verbindet. Darunter arbeiten die fachlichen Services, die einzelne Operationen ausführen, ohne den Gesamtablauf zu kennen.
Jede Schicht hat ihr eigenes Wissen. Das Gateway kennt Identitäten, Limits und Routen. Die Orchestrierung kennt Abläufe, Reihenfolgen und Kompensationen. Die Services kennen ihre Domäne. Probleme entstehen zuverlässig dann, wenn Wissen in die falsche Schicht wandert, etwa wenn das Gateway anfängt, Reihenfolgen zu kennen, oder wenn ein fachlicher Service nebenbei Rate Limits durchsetzt.
| Das Gateway macht | Das Gateway macht nicht |
|---|---|
| Authentifizierung und Autorisierung pro Request | Den Zustand eines Geschäftsvorgangs halten |
| Routing, Rate Limiting, TLS-Terminierung | Reihenfolgen mehrerer Aufrufe steuern |
| Request-Logging und Traffic-Metriken | Daten von einem Aufruf in den nächsten übergeben |
| Schutz der Services vor Überlast und Missbrauch | Fehlgeschlagene Schritte kompensieren |
| Leichte Anpassungen wie Header-Umschreibung | Fachliche Entscheidungen im Ablauf treffen |
Die rechte Spalte ist dabei keine Liste fehlender Funktionen, die ein besseres Gateway irgendwann nachliefert. Sie beschreibt Aufgaben, die ein anderes Wissen und einen anderen Lebenszyklus haben und deshalb in eine andere Schicht gehören.
Der Unterschied wird deutlich, wenn man die beiden Konfigurationen nebeneinanderlegt. Eine Gateway-Route legt fest, wohin ein einzelner Request unter welchen Bedingungen geht. Ein Orchestrierungs-Schritt beschreibt, was nach ihm kommt und welche Daten dorthin fließen.
route:
path: /orders
methods: [POST]
upstream: order-service
rateLimit: 100/min
auth: jwt
# Orchestrierungs-Schritt: Teil eines Ablaufs mit Datenfluss
- stepId: authorizePayment
operationId: authorizePayment
parameters:
- name: reservationId
value: $steps.reserveStock.outputs.reservationId
onFailure:
- type: goto
stepId: releaseStock
Schon die Vokabeln verraten die Schicht. Die Route spricht von Pfaden, Limits und Upstreams, also von Datenverkehr. Der Schritt hingegen spricht von Vorgängern, Datenübergaben und Fehlerpfaden, also von Abläufen. Wer in seiner Gateway-Konfiguration Begriffe aus der zweiten Welt entdeckt, hat die Vermischung bereits im Haus.
Betrieb und Verantwortung trennen sich ebenfalls
Auch organisatorisch leben die beiden Bausteine unterschiedlich. Ein Gateway ist Infrastruktur. Es gehört üblicherweise einem Plattform-Team, ändert sich selten und gilt als kritische Komponente, deren Ausfall alle APIs gleichzeitig trifft. Änderungen daran durchlaufen entsprechend vorsichtige Prozesse, und das ist auch richtig so.
Ein orchestrierter Ablauf ist dagegen Fachlichkeit. Er gehört dem Team, das den Geschäftsprozess verantwortet, und er ändert sich, wann immer sich der Prozess ändert, also vergleichsweise oft. Ein neuer Schritt im Onboarding, eine geänderte Reihenfolge bei der Bestellung, ein zusätzlicher Prüfpunkt im Kreditantrag, all das sind fachliche Änderungen, die schnell und ohne Plattform-Ticket umsetzbar sein müssen.
Diese unterschiedlichen Taktraten sind ein eigenständiges Argument für die Trennung. Wandert Ablauf-Logik ins Gateway, erbt sie dessen vorsichtigen Änderungsprozess, und fachliche Anpassungen werden künstlich langsam. Umgekehrt würde ein Gateway, das im Wochentakt fachliche Änderungen aufnimmt, seine Rolle als stabile, berechenbare Infrastruktur verlieren. Jede Schicht braucht das Änderungstempo, das zu ihrem Inhalt passt.
Eine Randnotiz zum Backend-for-Frontend, das in diese Diskussion gehört. Ein Backend-for-Frontend bündelt Aufrufe für genau einen Konsumenten-Typ, etwa die mobile App, und darf dafür auch aggregieren. Es ist damit weder Gateway noch Orchestrierung, eine konsumentenspezifische Fassade eben. Sobald ein Backend-for-Frontend allerdings schreibende Ketten mit Kompensation steuert, gilt dieselbe Grenze wie beim Gateway, und die Ablauf-Logik verdient eine eigene Schicht.
Woher die Verwechslung kommt
Dass die beiden Bausteine so oft in einen Topf geraten, hat nachvollziehbare Gründe. Der erste liegt in den Produkten selbst. Viele Gateways bieten Funktionen an, die in Richtung Ablauf-Steuerung zeigen, etwa Response-Aggregation, mit der ein Aufruf die Ergebnisse mehrerer Services gebündelt zurückbekommt, oder kleine Request-Pipelines mit bedingter Weiterleitung. Solche Funktionen sind für Lesezugriffe praktisch und völlig legitim. Sie sehen aber aus wie Orchestrierung, und genau dadurch entsteht der Eindruck, das Gateway könne diese Rolle gleich mit übernehmen.
Der zweite Grund ist sprachlich. Beide Bausteine werden gern als „die Schicht zwischen Konsument und Services" beschrieben, und in Architektur-Diagrammen landen sie als ähnlich aussehende Kästen an ähnlicher Stelle. Wer die Diagramme kennt, die Betriebsrealität aber nicht, hält sie für austauschbar.
Der dritte Grund ist der ehrlichste. Ein Gateway ist meist schon da, bezahlt und betrieben. Die Versuchung, eine neue Anforderung in die vorhandene Komponente zu legen, statt eine weitere einzuführen, ist menschlich und budgetär verständlich. Kurzfristig spart das einen Baustein, langfristig verschiebt es Ablauf-Logik an einen Ort, der dafür weder gedacht noch gut zu testen ist.
In einem Projekt bei einer Bank fanden wir die Logik eines Kreditantrags in den Routing-Regeln des Gateways wieder, gewachsen über zwei Jahre aus kleinen, jeweils harmlosen Erweiterungen. Die Regeln riefen nacheinander drei Services auf und werteten Zwischenergebnisse aus. Getestet wurde diese Logik praktisch nicht, weil die Gateway-Konfiguration außerhalb der üblichen CI-Pipelines lag, und jede Änderung brauchte das zentrale Plattform-Team. Nach dem Umzug der Ablauf-Logik in einen eigenen Orchestrierungs-Service sank die Durchlaufzeit für Änderungen von Wochen auf Tage, und das Gateway kehrte zu seiner eigentlichen Aufgabe zurück.
Wenn das Gateway orchestriert
Das Muster aus der Beobachtung hat einen Namen verdient, denn es wiederholt sich branchenübergreifend. Ein Gateway beginnt, Abläufe zu steuern, und wird damit langsam zu einem Orchestrierer ohne dessen Eigenschaften. Es fehlen die Zustandshaltung für langlaufende Vorgänge, die Kompensations-Logik, die Testbarkeit und meist auch die Zuständigkeit, weil das Gateway einem Plattform-Team gehört und der Ablauf einem Fachbereich.
Drei Warnsignale zeigen, dass diese Entwicklung begonnen hat.
- In der Gateway-Konfiguration tauchen Aufruf-Ketten auf, bei denen das Ergebnis eines Backends über die Weiterleitung an das nächste entscheidet.
- Änderungen an einem fachlichen Ablauf erfordern Tickets beim Plattform-Team, obwohl kein Querschnittsthema betroffen ist.
- Die Gateway-Konfiguration wächst schneller als die Zahl der APIs, weil sie Logik aufnimmt, die mit der Steuerung des Datenverkehrs nichts zu tun hat.
Wer eines dieser Signale erkennt, muss nicht in Panik verfallen, sollte den Trend aber stoppen, bevor die Konfiguration zur ungetesteten Nebenstelle der Geschäftslogik wird. Die Ablauf-Logik gehört in eine eigene Schicht, ob als Code in einem Service oder als deklarative Beschreibung, etwa mit der Workflow-Spezifikation Arazzo, die der Artikel Was ist Arazzo vorstellt.
Die Grauzone der Aggregation
Fairerweise gibt es eine Zone, in der die Grenze wirklich unscharf ist. Reine Lese-Aggregation, bei der ein Aufruf Daten aus drei Services einsammelt und gebündelt zurückgibt, ist die mildeste Form der Mehrfach-Koordination. Es gibt keine Reihenfolge-Abhängigkeit, keinen Zustand und nichts zu kompensieren, weil nichts verändert wird. Diese Aufgabe kann ein Gateway oder ein Backend-for-Frontend übernehmen, ohne dass daraus ein Problem entsteht.
Die Grenze verläuft beim ersten schreibenden Schritt. Sobald ein Aufruf in der Kette Daten verändert und ein späterer Schritt von diesem Ergebnis abhängt, beginnt echte Orchestrierung mit allem, was dazugehört. Wo genau Aggregation aufhört und Orchestrierung anfängt, vertieft Composition mit Beispielen und einer Abgrenzungsmatrix.
Eine schnelle Prüffrage für die Zuordnung lautet, ob bei einem Abbruch in der Mitte etwas aufgeräumt werden müsste. Wenn ja, handelt es sich um Orchestrierung, und die Logik gehört nicht in das Gateway. Wenn nein, ist es Aggregation, und das Gateway darf sie übernehmen.
Wo API-Management und Portal dazukommen
Vollständig wird das Bild mit zwei weiteren Begriffen, die im selben Gespräch oft mitschwingen. API-Management bezeichnet die Disziplin rund um den Lebenszyklus von APIs, also Versionierung, Governance-Regeln, Zugriffssteuerung und Monetarisierung. Das Gateway ist dabei nur das Laufzeit-Werkzeug dieser Disziplin, gewissermaßen ihr ausführender Arm im Datenstrom. Ein Developer Portal wiederum macht die API-Landschaft für Menschen nutzbar, mit Katalog, Dokumentation und Self-Service-Onboarding, ein Thema, das der Artikel API Developer Portal ausführlich behandelt.
In dieses Gefüge ordnet sich die Orchestrierung als vierte, eigenständige Ebene ein. Sie ist weder Laufzeit-Infrastruktur wie das Gateway noch Governance-Disziplin wie das Management noch Mensch-Schnittstelle wie das Portal. Sie ist die Ebene, auf der aus einzelnen APIs fachliche Abläufe werden. Interessant wird die Verbindung zum Portal an einer Stelle, die oft übersehen wird. Wenn Abläufe als deklarative Workflows beschrieben sind, lassen sie sich im selben Katalog veröffentlichen wie die APIs selbst, und Konsumenten finden dann neben den zwölf Endpoints auch die Reihenfolge, in der sie zusammengehören.
Für Governance-Verantwortliche heißt das konkret, dass Orchestrierungs-Beschreibungen denselben Regeln unterliegen sollten wie API-Specs. Sie brauchen einen Eigentümer, eine Version, ein Review bei Änderungen und einen Platz im Katalog. Wer seine OpenAPI-Dokumente bereits diszipliniert pflegt, hat die Prozesse dafür schon im Haus und muss sie nur auf eine weitere Artefakt-Art ausdehnen.
Zusammenspiel statt Entweder-oder
Im Zielbild arbeiten beide Bausteine zusammen, jeder in seiner Schicht. Der Aufruf eines Konsumenten passiert zuerst das Gateway, das Identität prüft und Limits anwendet. Dahinter nimmt die Orchestrierung den Vorgang an, ruft die fachlichen Services in der richtigen Reihenfolge auf und nutzt dabei für jeden einzelnen Aufruf wiederum die Infrastruktur, die das Gateway bereitstellt. Die Steuerung des Datenverkehrs und die Steuerung der Abläufe ergänzen sich, weil sie unterschiedliche Fragen beantworten.
Die Antwort auf den Einwand vom Anfang heißt dabei selten „noch ein Produkt kaufen". Der erste orchestrierte Ablauf entsteht meist als schlanker eigener Service neben dem Gateway, beschrieben in einer Workflow-Spec, betrieben vom Team des Fachprozesses. Das Gateway bleibt, was es ist, und genau das ist der Punkt.
Prüfen Sie in Ihrer eigenen Gateway-Konfiguration, ob sich dort Aufruf-Ketten mit Ergebnis-Auswertung finden. Jede dieser Stellen ist ein Kandidat für eine explizite Orchestrierung und zugleich ein Risiko, solange sie bleibt, wo sie ist.