API-Gateway-Architekturdiagramm: Routing, Auth, Rate Limits und BFFs

Das API-Gateway ist die Box, die jedes Architekturdiagramm hat und kaum eines erklärt. Es sitzt am Rand und sammelt mit der Zeit Aufgaben an: Routing, Authentifizierung, Rate Limits, Umschreiben von Anfragen und manchmal Geschäftsregeln, die es nie hätte bekommen sollen. Wenn das Diagramm nur einen Pfeil durch ein Gateway-Symbol zeigt, kann niemand sagen, was davon es tut, und die Fragen kommen während eines Incidents statt in einem Review.

Dieser Beitrag baut ein API-Gateway-Architekturdiagramm für ein verbreitetes Setup: eine Web-App, Mobile-Apps und Partner hinter einem Gateway, mit einem Backend für jedes Frontend. Er zeigt, was das Gateway tun sollte und was nicht, wie Token-Prüfung und Rate Limits funktionieren und was du beschriften solltest, damit das Diagramm echte Fragen beantwortet.

Was ins Gateway gehört

Ein Load Balancer verteilt Anfragen auf Instanzen; er weiß nicht, wer der Aufrufer ist. Ein Service Mesh kümmert sich um den Traffic zwischen Services innerhalb des Systems. Das Gateway kümmert sich um den Traffic, der von außen kommt, und versteht Clients: ihre Tokens, ihre Routen und ihre Kontingente. Viele Systeme betreiben alle drei.

Token-Prüfung am Rand

Im Beispiel melden sich Clients beim Identitätsanbieter an und senden mit jeder Anfrage ein JSON Web Token (RFC 7519). Das Gateway prüft die Signatur mit den öffentlichen Schlüsseln des Anbieters, die es als JWKS-Dokument abruft und cacht, und prüft die Claims: den Aussteller (iss), die Zielgruppe (aud) und den Ablauf (exp).

Die aktuellen JWT-Best-Practices in RFC 8725 sind hier eine gute Richtschnur. Eine Bibliothek muss dich die erlaubten Algorithmen festlegen lassen und darf keine anderen verwenden, also konfiguriere die Liste, statt dem Header des Tokens zu vertrauen. Wenn ein Aussteller Tokens für mehrere Anwendungen erzeugt, muss das Token eine Zielgruppe tragen, und jede Anwendung muss prüfen, dass die Zielgruppe ihre eigene ist.

Ein gültiges Token sagt, wer der Aufrufer ist. Es sagt nicht, was er darf. Das Gateway kann einen fehlenden Scope abweisen, aber ob dieser Nutzer diese Bestellung ändern darf, entscheidet weiterhin der Service.

Rate Limits

Zähle pro Client, nicht pro IP-Adresse. Hinter einem NAT können sich viele Nutzer eine Adresse teilen, und ein einzelner Scraper kann viele Adressen nutzen. Binde das Limit an den API-Schlüssel, den OAuth-Client oder den Nutzer.

Teile die Zähler. Bei mehreren Gateway-Instanzen, die jeweils selbst zählen, wird aus einem Limit von 100 pro Minute ein Limit von 100 pro Instanz. Ein gemeinsamer Speicher wie Redis führt über alle Instanzen hinweg einen Zähler pro Client.

Wähle einen Algorithmus und schreib ihn auf. Ein festes Fenster wird jede Minute zurückgesetzt und erlaubt Lastspitzen an der Grenze. Ein gleitendes Fenster glättet das. Ein Token Bucket erlaubt kurze Spitzen bis zu einer festgelegten Größe und hält dabei eine durchschnittliche Rate.

Antworte mit 429. RFC 6585 definiert 429 Too Many Requests. Die Antwort sollte die Situation erklären und kann Retry-After enthalten, das RFC 9110 als HTTP-Datum oder als Anzahl zu wartender Sekunden definiert. RFC 6585 sagt nicht, wie der Server den Client erkennt oder Anfragen zählt: Dieser Teil ist dein Design, also gehört er ins Diagramm. Ein IETF-Entwurf definiert standardisierte Header-Felder RateLimit und RateLimit-Policy, ist aber zum Zeitpunkt dieses Beitrags (Oktober 2026) noch ein Entwurf.

Entscheide, was passiert, wenn der Zählerspeicher ausfällt. Fail open hält die API ohne Limits am Laufen; fail closed schützt die Services und weist Traffic ab. Beides kann richtig sein, solange es eine Entscheidung ist und kein Zufall.

Backends for Frontends

Sam Newmans Muster Backends For Frontends ersetzt ein universelles API-Backend durch eine serverseitige Komponente pro Nutzererlebnis. Jedes BFF ist eng auf eine einzige UI ausgerichtet und wird meist von dem Team gepflegt, das diese UI baut, sodass das Team die API ändern kann, wenn sich seine Screens ändern. Ein gemeinsames, universelles Backend wird leicht zum Engpass, und der Artikel merkt an, dass aggregierende Edge-Services dazu neigen, aufgeblähten Code anzusammeln.

Wie viele BFFs? Newman schreibt Stewart Gleadow eine einfache Regel zu: ein Erlebnis, ein BFF. Bieten zwei Apps dasselbe Erlebnis und gehören beide demselben Team, können sie sich eines teilen; SoundCloud zum Beispiel nutzt ein BFF für seine iOS- und Android-Apps für Hörer.

Partner sind anders. Sie brauchen eine stabile, versionierte API, keine, die um einen Screen herum geformt ist, also gehen ihre Routen ohne BFF zur öffentlichen API der Services.

Das Beispiel: ein Onlineshop

Der Shop hat eine React-Web-App, iOS- und Android-Apps und Partner, die über eine API Bestellungen anlegen. Eine WAF filtert den Traffic vor dem Gateway. Das Gateway prüft Tokens, zählt Anfragen pro Client in Redis und routet nach Pfadpräfix. Das Web-Team und das Mobile-Team haben je ein eigenes BFF, und beide BFFs rufen die Services Orders, Catalog und Accounts im privaten Netz auf. Partneraufrufe gehen direkt an die versionierte API des Orders-Service.

So liest du es:

• Von links nach rechts, eine Anfrage. Ein Client ruft über die WAF das Gateway auf, das die Anfrage zu einem BFF oder zur Partner-API routet.
• Gestrichelte Kanten liegen außerhalb des Anfragepfads. Die Web-App meldet sich beim Identitätsanbieter an, und das Gateway holt die Signaturschlüssel des Anbieters und cacht sie.
• Unter dem Gateway hält Redis die Rate-Limit-Zähler, die alle Gateway-Instanzen teilen.
• Im privaten Netz ruft jedes BFF nur die Services auf, die seine Screens brauchen.
• Der Markdown-Block ist die Gateway-Policy: was das Gateway prüft, das Limit und was es den Services überlässt.

Was du beschriften solltest

• Routen für jedes Backend, als Pfadpräfixe oder Hosts.
• Authentifizierung an jedem Eingang: der Token-Typ, wer ihn ausstellt und was das Gateway prüft.
• Limits: der Schlüssel, Anzahl und Fenster und was der Client zurückbekommt.
• Timeouts und Retries am Gateway. Retries am Rand vervielfachen die Last auf einem angeschlagenen Service.
• Verhalten bei Ausfällen, wenn der Identitätsanbieter, der Zählerspeicher oder ein Backend nicht erreichbar ist.
• Verantwortung. Die Gateway-Konfiguration gehört oft dem Platform-Team; die BFFs gehören den UI-Teams.

Häufige Fehler

• Geschäftslogik im Gateway. Umschreibungen und Bedingungen wachsen zu Regeln, die niemand testen kann. Halte das Gateway schlank.
• Das Gateway als einzige Sicherheitsprüfung. Services dahinter sollten einer Anfrage nicht nur deshalb vertrauen, weil sie angekommen ist. Das Zero-Trust-Architekturdiagramm zeigt, wie du Prüfungen an jedem Hop zeichnest.
• Limits nur pro IP, die Nutzer hinter geteilten Adressen bestrafen und Clients übersehen, die Adressen wechseln.
• Lokale Zähler auf jeder Instanz, die das Limit mit der Zahl der Instanzen multiplizieren.
• Ein BFF für alles, das wieder ein universelles Backend ist.
• Ein 429 ohne Details. Clients, die nicht wissen, wie lange sie warten sollen, raten, und meist raten sie zu kurz.

Was hinter dem Gateway liegt, zeigt das Microservices-Architekturdiagramm. Unter Kubernetes behandelt das Kubernetes-Ingress-Diagramm die Schicht, die oft vor dem Gateway sitzt oder Teile davon ersetzt.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem C4-Modell-Pack einen Container für die Web-App und einen für die Mobile-App hinzu und ein Externes System für den Partner.
3. Füge aus dem Sicherheits-Pack eine WAF und einen Identitätsanbieter hinzu.
4. Füge aus dem Cloud-Pack ein API-Gateway hinzu und aus dem Daten-Pack einen Redis-Node für die Rate-Limit-Zähler.
5. Füge aus dem Basis-Pack einen Rahmen namens Private network hinzu, darin Container-Nodes aus dem C4-Modell-Pack für die beiden BFFs und die drei Services.
6. Verbinde sie von links nach rechts, beschrifte jede Route mit ihrem Pfad und zeichne Anmeldung und Schlüsselabruf gestrichelt. Füge einen Markdown-Block aus dem Basis-Pack mit der Gateway-Policy hinzu.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Ist ein API-Gateway dasselbe wie ein Load Balancer? Nein. Ein Load Balancer verteilt Anfragen auf Instanzen. Ein Gateway versteht API-Anfragen: Routen, Tokens und Kontingente. Viele Gateways laufen hinter einem Load Balancer.

Brauche ich ein Service Mesh, wenn ich ein API-Gateway habe? Beide lösen verschiedene Probleme. Das Gateway kümmert sich um Traffic von außen; ein Mesh um Aufrufe zwischen Services, etwa mit mutual TLS und Retries. Zeichne sie getrennt, wenn du beides betreibst.

Sollten Services das Token prüfen, wenn das Gateway es schon getan hat? Ja, für die Claims, auf die sie sich verlassen. Das Gateway weist schlechte Tokens früh ab, und jeder Service autorisiert die Aktion trotzdem selbst.

Wie viele BFFs sollte ich haben? Eines pro Nutzererlebnis. Zwei Apps mit demselben Erlebnis und demselben verantwortlichen Team können sich eines teilen.

Was sollte eine 429-Antwort enthalten? Eine kurze Erklärung und einen Retry-After-Header mit der Anzahl zu wartender Sekunden, damit Clients zurückweichen, statt sofort erneut zu versuchen.

Kostenlos starten — ein Seat, keine Kreditkarte.