API-Gateway-Patterns: REST-APIs zentral absichern statt in jedem Service neu

1. Das Problem, das ein API-Gateway löst

In einer Microservice-Architektur mit mehreren unabhängigen REST-APIs entsteht schnell dasselbe Muster mehrfach: Jeder Service prüft eigenständig einen Auth-Token, setzt eigene Rate-Limits durch, loggt Requests in einem eigenen Format. Diese Logik in jedem Service separat zu implementieren führt nicht nur zu Codeduplikation, sondern auch zu Inkonsistenzen, wenn ein Team ein Detail anders umsetzt als ein anderes. Bei einem Sicherheitsupdate, etwa einer neuen Anforderung an die Token-Validierung, müssten ohne zentrale Stelle alle Services gleichzeitig angepasst und neu deployt werden, was in der Praxis selten reibungslos gelingt.

Ein API-Gateway steht als zentrale Schicht vor allen Backend-Services und übernimmt diese Querschnittsaufgaben an einer Stelle. Clients sprechen nur noch mit dem Gateway, das Requests validiert, anreichert und an den zuständigen Backend-Service weiterleitet. Der Vorteil liegt in der Konsistenz und der Möglichkeit, Sicherheits- oder Observability-Anforderungen an einer einzigen Stelle zu ändern, statt jeden Service einzeln anzupassen.

2. Routing-Pattern: ein Einstiegspunkt für viele Services

Das grundlegendste Gateway-Pattern ist reines Routing: Der Client kennt nur eine öffentliche Domain, das Gateway leitet basierend auf dem URL-Pfad an den zuständigen Backend-Service weiter. /api/orders/* geht an den Order-Service, /api/customers/* an den Customer-Service, ohne dass der Client wissen muss, wie viele Services tatsächlich dahinterstehen oder wie sie intern erreichbar sind.

Dieses Pattern entkoppelt die externe API-Struktur von der internen Service-Aufteilung: Ein Team kann einen Service intern in zwei kleinere Services aufteilen, ohne dass sich für Konsumenten der API etwas ändert, solange die Routing-Regeln im Gateway entsprechend angepasst werden. Das macht interne Refactorings deutlich risikoärmer für externe Integratoren.

# traefik-gateway.yaml — Routing-Regeln nach Pfad-Praefix
http:
  routers:
    orders-router:
      rule: "PathPrefix(`/api/orders`)"
      service: order-service
      middlewares:
        - rate-limit
        - jwt-auth

    customers-router:
      rule: "PathPrefix(`/api/customers`)"
      service: customer-service
      middlewares:
        - rate-limit
        - jwt-auth

  services:
    order-service:
      loadBalancer:
        servers:
          - url: "http://order-service:8080"
    customer-service:
      loadBalancer:
        servers:
          - url: "http://customer-service:8080"

3. Authentifizierung an einer Stelle statt in jedem Service

Statt dass jeder Backend-Service selbst ein JWT validiert, übernimmt das Gateway diese Aufgabe zentral: Es prüft Signatur, Ablaufdatum und Scopes des Tokens, und leitet den Request nur bei erfolgreicher Prüfung an den Backend weiter, oft mit angereicherten Headern wie X-User-Id für den Backend-Service. Der Backend-Service selbst muss dann kein eigenes Auth-Handling mehr implementieren, sondern vertraut darauf, dass nur bereits geprüfte Requests bei ihm ankommen.

Dieses Vertrauen setzt voraus, dass Backend-Services nicht direkt von außen erreichbar sind, sondern ausschließlich über das Gateway, typischerweise durch Netzwerksegmentierung oder ein internes Service-Mesh abgesichert. Ohne diese Absicherung wäre die zentrale Auth-Prüfung im Gateway wertlos, weil ein Angreifer den Backend-Service direkt und ohne Gateway-Prüfung ansprechen könnte.

4. Rate-Limiting zentral statt pro Service konfiguriert

Rate-Limiting im Gateway erlaubt es, Limits konsistent über alle Services hinweg durchzusetzen, etwa pro API-Key oder pro authentifiziertem Nutzer, unabhängig davon, welchen Backend-Service ein Request am Ende erreicht. Das verhindert, dass ein Client durch geschicktes Verteilen seiner Requests über mehrere Services die Rate-Limits eines einzelnen Services umgeht.

Gängige Gateway-Implementierungen wie Kong, Traefik oder Envoy bieten eingebaute Rate-Limiting-Module mit unterschiedlichen Algorithmen (Token Bucket, Sliding Window), die sich per Konfiguration statt per Code aktivieren lassen. Für ein Team bedeutet das, Rate-Limiting-Regeln ändern zu können, ohne einen einzigen Backend-Service neu deployen zu müssen. Unterschiedliche Limits für unterschiedliche Kundensegmente, etwa großzügigere Grenzwerte für zahlende Enterprise-Kunden, lassen sich so ebenfalls zentral pflegen, statt in jedem Backend-Service dieselbe Kundensegment-Logik zu duplizieren.

5. Backend for Frontend: ein Gateway pro Client-Typ

Eine Weiterentwicklung des einfachen Gateway-Patterns ist Backend for Frontend (BFF): Statt eines einzigen Gateways für alle Client-Typen wird für jeden Client-Typ (Web, iOS, Android) ein eigenes, spezialisiertes Gateway betrieben, das die Backend-Services genau auf die Bedürfnisse dieses Clients zuschneidet, etwa mit aggregierten Responses oder client-spezifischer Feldreduktion.

Der Vorteil liegt darin, dass ein mobiler Client, der aus Bandbreitengründen minimale Payloads braucht, ein anderes Response-Format bekommen kann als eine Web-App, ohne dass die zugrundeliegenden Backend-Services selbst mehrere Response-Varianten anbieten müssen. Der Nachteil ist zusätzlicher Betriebs- und Wartungsaufwand für mehrere Gateway-Instanzen statt einer einzigen.

6. Request-Aggregation: mehrere Backend-Calls zu einer Antwort bündeln

Ein weiteres verbreitetes Gateway-Pattern ist die Aggregation mehrerer Backend-Aufrufe zu einer einzigen Client-Antwort. Statt dass ein Client für eine Produktdetailseite drei separate Requests an Produkt-, Preis- und Lagerbestand-Service schickt, ruft das Gateway alle drei intern auf und kombiniert die Ergebnisse zu einer Response, was die Anzahl der Client-Server-Roundtrips reduziert.

Diese Aggregation muss sorgfältig mit Fehlerbehandlung kombiniert werden: Wenn einer von drei aggregierten Backend-Aufrufen fehlschlägt, muss das Gateway entscheiden, ob es die gesamte Antwort mit Fehler zurückgibt oder eine Teilantwort mit einem markierten fehlenden Feld liefert. Diese Entscheidung sollte explizit dokumentiert sein, damit Client-Entwickler nicht von unerwartetem Verhalten überrascht werden. Zusätzlich sollten die parallelen Backend-Aufrufe mit individuellen Timeouts abgesichert werden, damit ein einzelner, langsam antwortender Service nicht die gesamte aggregierte Antwort blockiert.

<?php
// Symfony: Aggregations-Endpoint im BFF-Gateway
#[Route('/bff/product/{sku}', methods: ['GET'])]
public function productDetail(string $sku): JsonResponse
{
    $product = $this->productClient->get($sku);
    $price = $this->pricingClient->getPrice($sku);
    $stock = $this->inventoryClient->getStock($sku);

    // Teilausfall wird explizit markiert statt den ganzen Request scheitern zu lassen
    return $this->json([
        'product' => $product,
        'price' => $price ?? ['available' => false],
        'inStock' => $stock->quantity > 0,
        'degraded' => $price === null,
    ]);
}

7. Der Single Point of Failure: Ausfallsicherheit des Gateways

Ein zentrales Gateway wird zwangsläufig zu einem kritischen Bestandteil der gesamten Infrastruktur: Fällt es aus, ist die gesamte API nicht mehr erreichbar, selbst wenn alle Backend-Services problemlos laufen. Das erfordert, das Gateway selbst hochverfügbar zu betreiben, üblicherweise mit mehreren redundanten Instanzen hinter einem Load Balancer.

Ebenso wichtig ist, dass das Gateway selbst keine komplexe Geschäftslogik enthält, sondern auf reine Querschnittsaufgaben (Routing, Auth, Rate-Limiting) beschränkt bleibt. Ein Gateway, das zusätzlich fachliche Logik übernimmt, wird selbst zu einem Monolithen mit denselben Skalierungs- und Deployment-Problemen, die die Microservice-Architektur eigentlich vermeiden sollte. Health-Checks und automatisches Circuit-Breaking gegenüber ausfallenden Backend-Services gehören ebenfalls zur Grundausstattung eines produktionsreifen Gateways, damit ein einzelner gestörter Backend-Service nicht die Erreichbarkeit aller anderen Services über das Gateway mit beeinträchtigt.

8. Der zusätzliche Netzwerk-Hop und seine Latenz-Kosten

Jeder Request durchläuft mit einem Gateway einen zusätzlichen Netzwerk-Hop gegenüber direkter Kommunikation mit dem Backend-Service. In den meisten Fällen ist diese zusätzliche Latenz (typischerweise wenige Millisekunden bei einem performanten Gateway) vernachlässigbar gegenüber der Latenz der eigentlichen Backend-Verarbeitung, insbesondere bei Datenbankzugriffen, die üblicherweise um ein Vielfaches länger dauern.

Bei latenzkritischen internen Aufrufen zwischen Services (nicht Client-zu-Gateway, sondern Service-zu-Service) wird das Gateway meist bewusst umgangen, und Services kommunizieren direkt miteinander oder über ein leichtgewichtiges Service-Mesh. Das Gateway-Pattern gilt primär für den externen Eintrittspunkt in das System, nicht zwingend für jede interne Kommunikation.

9. Verbreitete Gateway-Implementierungen im Vergleich

Die Wahl der konkreten Gateway-Software hängt von Team-Erfahrung, bestehender Infrastruktur und den benötigten Features ab. Die folgende Tabelle vergleicht verbreitete Optionen.

10. Zusammenfassung

11. FAQ: API-Gateway-Patterns: Das Wichtigste auf einen Blick