Was ist API-Orchestrierung?

API-Orchestrierung ist ein Muster, bei dem eine koordinierende Schicht mehrere APIs nacheinander aufruft und ein einziges kombiniertes Ergebnis zurückgibt. Das Bild vom Dirigenten ist überall zu lesen, weil es genau passt: Jede API spielt ihren Part, aber die Partitur – Reihenfolge, Abhängigkeiten, was passiert, wenn die Blechbläser patzen – liegt beim Orchestrator. Eine Verwechslung sollte sofort vom Tisch: Die halbe Branche benutzt “Orchestrierung” für das, was die eigene Produktkategorie tut (Gateways, Automatisierungsplattformen, Workflow-Engines und GraphQL-Router beanspruchen das Wort alle für sich). Dieser Artikel meint das Muster selbst – und ordnet die Produkte weiter unten ein.

Das Wichtigste in Kürze

Der Checkout, orchestriert

// JavaScript — Cloud Code (cloud/main.js)
// Lightweight orchestration: one function owns the checkout flow
Parse.Cloud.define('checkout', async (req) => {
  const { cartId } = req.params;

  // Independent lookups run in PARALLEL (~200 ms, not 400)
  const [cart, address] = await Promise.all([
    loadCart(cartId),
    loadAddress(req.user),
  ]);

  const reservation = await reserveInventory(cart);        // step 1
  try {
    const charge = await chargeCard(req.user, cart, {
      idempotencyKey: cartId,                              // safe to retry
    });
    const shipment = await createShipment(charge, address); // step 3
    return { orderId: shipment.orderId };                  // one response out
  } catch (e) {
    await releaseInventory(reservation); // compensate — no rollback exists
    throw e;
  }
});

// Flutter / Dart — Back4app Flutter SDK
// The client sees ONE call — the orchestrator owns the sequence
final result = await ParseCloudFunction('checkout')
    .execute(parameters: {'cartId': cartId});
showConfirmation(result.result['orderId']);
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.

// iOS / Swift — Back4app Swift SDK
// The client sees ONE call — the orchestrator owns the sequence
let result: [String: String] = try await Cloud.run(
    name: "checkout", parameters: ["cartId": cartId])
showConfirmation(result["orderId"] ?? "")
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.

// Android / Kotlin — Back4app Android SDK
// The client sees ONE call — the orchestrator owns the sequence
val params = mapOf("cartId" to cartId)
val result = ParseCloud.callFunction<Map<String, Any>>("checkout", params)
showConfirmation(result["orderId"] as String)
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.

Alles, was das Muster ausmacht, in einer Funktion: unabhängige Abfragen parallelisiert, abhängige Schritte sequenziert, ein Idempotenzschlüssel, der den gefährlichen Schritt wiederholbar macht, und eine Kompensation im catch-Block – denn die Bestandsreservierung gibt sich nicht von selbst frei, wenn die Karte abgelehnt wird.

Gateway vs. BFF vs. Aggregation vs. Orchestrierung vs. Choreografie

Die Fünfertabelle, die kein einzelner Wettbewerber liefert:

Die letzten beiden Zeilen sind das eigentliche Paar, gespiegelt im EDA-Artikel mit derselben Regel: Orchestrieren Sie, wenn jemand für das Ergebnis eines Workflows geradestehen muss; choreografieren Sie, wenn Produzenten wirklich nicht interessiert, was danach passiert. Orchestratoren sprechen in Befehlen (Imperativ, ablehnbar), die Choreografie spricht in Ereignissen (Fakten in der Vergangenheitsform) – dieselbe Unterscheidung, nur auf Architekturebene.

Wenn Schritt 3 von 5 scheitert

Der Abschnitt, den die Suchergebnisse auslassen, und der Grund, warum Orchestrierung Ingenieursarbeit ist und keine Klempnerei. Verteilte Schritte haben keine gemeinsame Transaktion: Eine abgeschlossene Belastung lässt sich nicht von einer Datenbank zurückrollen, die nie davon wusste. Das Saga-Muster ist die ehrliche Antwort – jeder Schritt ist eine lokale Aktion mit einer kompensierenden Gegenaktion (Belastung ↔ Erstattung, Reservierung ↔ Freigabe), und im Fehlerfall laufen die Kompensationen für alles bereits Erledigte. Drei Disziplinen machen es tragfähig: Idempotenzschlüssel auf den gefährlichen Schritten, damit Zeitüberschreitung plus Wiederholung nicht doppelt abrechnet (die mit demselben Schlüssel wiederholte Zahlung wird erkannt, nicht ausgeführt); Zeitüberschreitungen pro Schritt, damit eine hängende Abhängigkeit nicht den ganzen Ablauf hängen lässt; und explizite Endzustände, denn ein Ablauf, der halb durchlief und dann kompensiert wurde, ist ein bekanntes Ergebnis, das festgehalten gehört, und keine Ausnahme zum Verschlucken. Der Vorzug der Orchestrierung ist, dass all dies an einer sichtbaren Stelle lebt – was zugleich ihr Preis ist: Diese Stelle muss skaliert, überwacht und ehrlich gehalten werden.

Die Latenzrechnung

Drei Aufrufe zu je 200 ms: nacheinander = 600 ms, parallel = ~200 ms. Die erste Optimierung des Orchestrators ist weder Caching noch ein raffinierter Transport – es ist das ehrliche Lesen des Abhängigkeitsgraphen: Warenkorb und Adresse (unabhängig) laden gemeinsam, die Belastung (braucht den Warenkorb) wartet, der Versand (braucht die Belastung) wartet darauf. Die meisten orchestrierten Abläufe sind ein kurzes sequenzielles Rückgrat mit parallelen Zweigen daran, und jeder fälschlich aufs Rückgrat gesetzte Schritt ist für Nutzer sichtbare Latenz, verschenkt für nichts.

Code oder Engine?

Eine schlichte Funktion genügt, wenn der Ablauf kurz und synchron ist: eine Handvoll Schritte, ein Budget von Sekunden, und “es ist fehlgeschlagen” ist eine akzeptable Antwort an einen wartenden Client – das beschreibt den Orchestrierungsbedarf der meisten App-Backends und ist genau das, was eine serverseitige Funktion bietet. Eine dauerhafte Workflow-Engine (Open-Source-Beispiele: Temporal, Camunda) rechtfertigt ihr Betriebsgewicht, wenn Abläufe lange laufen (Minuten bis Tage), Prozessneustarts mitten im Ablauf überstehen müssen oder geplante Wiederholungsversuche, menschliche Freigabeschritte und eine wiederabspielbare Historie brauchen. Der Aufstiegspfad ist real, aber selten dringend; das Anti-Muster ist eine Engine für einen Checkout mit drei Aufrufen – oder handgestrickter dauerhafter Zustand in einer Funktion, die still und leise selbst zur Engine geworden ist.

Typische Anwendungsfälle

• Checkout- und Zahlungsabläufe – die kanonische abhängige Abfolge, bei der es um Geld geht.
• Nutzer-Onboarding – Konto anlegen, Identität prüfen, Ressourcen bereitstellen, Willkommensnachricht senden: geordnet und kompensierbar.
• Zusammenbau mobiler Ansichten – ein orchestrierter Aufruf ersetzt drei geschwätzige Roundtrips über ein Netz mit hoher Latenz.
• Bündel von Drittanbietern – KYC-Prüfungen, Versandangebote, Anreicherung: mehrere Anbieter, eine Antwort, Schlüssel serverseitig gehalten.
• Migrationsnähte – ein Orchestrator verbirgt die Aufteilung zwischen Alt- und Neusystem hinter einer stabilen API, während der Monolith zerlegt wird.

Sollten Sie orchestrieren? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Der Orchestrator zieht Abhängigkeiten an. Er kennt jeden Dienst im Ablauf; Änderungen weiter unten schwappen zu ihm hoch – Sichtbarkeit und Kopplung sind dieselbe Eigenschaft.
• Er liegt auf dem heißen Pfad. Jeder Ablauf führt durch ihn, also gehören seine Latenz, seine Skalierung und sein Verfügbarkeitsbudget zum Produkt und nicht in die Infrastrukturfußnote.
• Kompensation ist kein Rückgängigmachen. Eine Erstattung ist ein neues Ereignis mit eigenen Fehlerquellen, keine Zeitmaschine; Sagas tauschen Atomarität gegen Explizitheit, und diese Explizitheit muss behandelt werden.
• Geschäftslogik wandert ein. Ohne Regeln saugt der Orchestrator Entscheidungen auf, die in die Dienste gehören, denen die Daten gehören – Abfolge hier, Semantik dort.
• Synchrone Orchestrierung erbt synchrone Grenzen. Ein Client, der fünf Schritte lang wartet, wartet eben; Abläufe, die über das Anfragefenster hinauswachsen, gehören zu Jobs mit Status und nicht zu längeren Zeitüberschreitungen.

Orchestrierung mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Leichtgewichtige Orchestrierung ist genau das, was eine Cloud-Code-Funktion von Natur aus tut, und die Code-Tabs zeigen das vollständige Muster: eine checkout-Funktion, die die unabhängigen Lesezugriffe parallelisiert, die abhängigen Schritte sequenziert, die Schlüssel der Drittanbieter serverseitig hält, im catch-Block kompensiert und einem mobilen Client, der genau einen Aufruf gemacht hat, eine Antwort zurückgibt. Die Funktion läuft neben der Datenbank (Bestellzustand und Endergebnisse sind einen Schreibvorgang entfernt), der Auth-Kontext kommt in request.user an, und es gibt keine separate Orchestrierungsschicht zum Deployen oder Skalieren. Wenn ein Ablauf eines Tages über das Anfragefenster hinauswächst – Freigaben, Wartezeiten von einem Tag –, ist das der Aufstieg zur Workflow-Engine; bis dahin ist der Orchestrator eine Datei in Ihrem Repository.