Zum Hauptinhalt springen

API Gateway

Einleitung​

Ein API Gateway ist ein Edge-Pattern, das als zentraler Einstiegspunkt für Clients dient.

Es bündelt:

  • Routing
  • Authentisierung
  • Rate Limiting
  • Observability
  • Cross-Cutting Policies

Es löst kein Fachproblem –
es löst ein Integrationsproblem.

Einordnung

Ebene: Meso-Pattern (Edge Layer)
Typische Kontexte: Microservices, SOA, Cloud-native
Ziel: Reduktion von Client-Komplexität und Standardisierung von Querschnittsfunktionen

Das Gateway sitzt am Rand des Systems – nicht im Kern.

Grundprinzip

Kernaussage:

  • Clients sprechen nur mit dem Gateway
  • Backend-Services bleiben verborgen
  • Policies werden zentral durchgesetzt

Aufgaben eines API Gateways

1️⃣ Routing​

  • Weiterleitung an passende Services
  • URL- oder Path-basiert
  • Versionierung von APIs

2️⃣ Authentisierung & Autorisierung​

  • Token-Validierung (z. B. JWT)
  • mTLS-Termination
  • Zugriffskontrolle

3️⃣ Rate Limiting & Quotas​

  • Schutz gegen Missbrauch
  • Schutz gegen Überlast

4️⃣ Observability​

  • Request-Logging
  • Correlation IDs
  • Monitoring
  • Metriken auf Edge-Ebene

5️⃣ Response-Aggregation (optional)​

  • Zusammenführung mehrerer Service-Responses
  • Reduzierung von Roundtrips

Aber:

Aggregation ≠ Business-Logik.

API Gateway vs. BFF

Ein Gateway ist generisch.

Ein Backend-for-Frontend (BFF) ist:

  • client-spezifisch
  • UI-orientiert
  • oft näher an Business-Logik

Viele Systeme kombinieren:

  • Zentrales API Gateway
  • Mehrere BFFs dahinter

Vorteile

  • Zentrale Sicherheitsdurchsetzung
  • Vereinfachte Client-Integration
  • Konsistente API-Policies
  • Entkopplung von Clients und Services
  • Kontrollierter Außenkontakt

Risiken / Anti-Patterns

1️⃣ Single Point of Failure​

Wenn nicht redundant betrieben, wird das Gateway zum Flaschenhals.

2️⃣ God Gateway​

Typischer Fehler:

  • Business-Logik im Gateway
  • Datenaggregation mit Fachregeln
  • Orchestrierung komplexer Prozesse

Dann entsteht:

Verteilter Monolith mit zentralem Kern.

3️⃣ Performance-Bottleneck​

  • Latenzakkumulation
  • Hohe Lastkonzentration
  • Unsaubere Timeout-Strategien

4️⃣ Verdeckte Kopplung​

Wenn alle Services nur über das Gateway sprechen, wird es faktisch zur zentralen Integrationslogik.

Eignung 2026

Sinnvoll bei:​

  • vielen externen Clients
  • Public APIs
  • Microservice-Landschaften
  • Bedarf an zentraler Security-Governance

Weniger sinnvoll bei:​

  • Einem einzelnen Service
  • Internen Systemen ohne Außenkontakt
  • Extrem latenzkritischen Direktverbindungen

Architekturelle Leitlinien

Ein gutes API Gateway:

  • enthält keine Business-Logik
  • ist horizontal skalierbar
  • ist stateless
  • delegiert fachliche Verantwortung
  • hat klare Ownership

Ein Gateway ist ein Edge-Control-Point, kein Orchestrator.

Fazit

Das API Gateway reduziert Integrationskomplexität – erhöht aber zentrale Verantwortung.

Es ist sinnvoll als:

Sicherheits- und Policy-Schicht am Systemrand.

Es ist gefährlich als:

fachlicher Integrationsknoten im Kern.