Das Muster entsteht schleichend: Erst gibt es eine API fürs CRM, dann eine fürs Kundenportal, dann eine für den Zahlungsdienst, dann eine für den neuen Partner. Jede prüft Tokens ein bisschen anders, jede loggt in ein anderes Format, jede hat eigene — oder gar keine — Limits. Wer wissen will, wer gestern auf welche Schnittstelle zugegriffen hat, muss vier Systeme befragen. Und wenn ein API-Key kompromittiert wird, beginnt die Suche, wo er überall gültig ist. Ein API-Gateway beendet diesen Wildwuchs, indem es sich als einzige Anlaufstelle vor alle Dienste setzt.
Was das Gateway übernimmt
Technisch ist ein Gateway ein spezialisierter Reverse Proxy: Anfragen kommen zentral an, werden geprüft und an den zuständigen Dienst weitergereicht. Der eigentliche Wert liegt in den Querschnittsaufgaben, die damit aus den einzelnen Diensten verschwinden:
- Authentifizierung und Autorisierung: Token-Prüfung, API-Keys und Berechtigungen werden einmal am Eingang durchgesetzt — kein Dienst muss eigene Auth-Logik pflegen.
- Rate Limiting und Quotas: Limits pro Kunde, pro Key oder pro Endpunkt schützen alle Dienste gleichzeitig — wie im Beitrag Rate Limiting beschrieben, nur eben zentral statt verstreut.
- Routing und Versionierung: Das Gateway entscheidet, welche Anfrage an welchen Dienst und welche Version geht — ein sauberes Fundament für API-Versionierung ohne Bruch.
- Einheitliches Logging und Monitoring: Jede Anfrage taucht in einem Format an einer Stelle auf. Latenzen, Fehlerraten und Auffälligkeiten sind pro Endpunkt sichtbar, nicht pro Zufallsfund.
- Schutzschicht: TLS-Terminierung, Header-Bereinigung und das Abfangen offensichtlich bösartiger Anfragen passieren, bevor irgendein Backend belastet wird.
Wann sich der zentrale Eingang lohnt
Die ehrliche Antwort: nicht ab Tag eins. Ein Monolith mit einer einzigen internen API braucht kein Gateway — dort reicht ein schlanker Reverse Proxy wie nginx. Interessant wird es an drei Schwellen. Erstens: mehrere Dienste, die dieselben Querschnittsaufgaben jeweils selbst lösen — spätestens beim dritten Dienst ist duplizierte Auth-Logik teurer als ein Gateway. Zweitens: externe Konsumenten — sobald Partner, Kunden oder Integrationen auf Schnittstellen zugreifen, braucht es Key-Verwaltung, Quotas und nachvollziehbare Zugriffsprotokolle. Drittens: Compliance und Audit — wer belegen muss, wer wann auf welche Daten zugegriffen hat, will genau einen Ort, an dem diese Antwort liegt.
Die Fallen, die niemand einplant
Das Gateway ist per Definition ein Nadelöhr — fällt es aus, sind alle Schnittstellen tot. Deshalb gilt: nie als einzelne Instanz betreiben. Mindestens zwei Instanzen hinter einem Load Balancer, Health Checks, Deployments ohne Downtime. Die zweite Falle ist Logik-Schleichfluss: Weil das Gateway so bequem zentral sitzt, wandern nach und nach Transformationen, Sonderfälle und Geschäftsregeln hinein — bis niemand mehr weiß, was der Dienst tut und was der Eingang dazudichtet. Geschäftslogik gehört in die Dienste, das Gateway bleibt dumm und schnell. Die dritte Falle ist Latenz: Jeder zusätzliche Hop kostet Millisekunden. Ein schlank konfiguriertes Gateway liegt im einstelligen Bereich — ein überladenes wird selbst zum Performance-Problem, das dann im Monitoring auffällt.
Faustregel: Ein Gateway lohnt sich, sobald dieselbe Querschnittsaufgabe zum dritten Mal in einem Dienst nachgebaut wird — oder sobald der erste externe Konsument einen API-Key bekommt. Vorher ist es Overhead, danach ist der Verzicht fahrlässig.
Pragmatischer Einstieg
Der Einstieg muss kein Großprojekt sein. Bewährt hat sich der Weg über den Bestand: Zuerst wird das Gateway als reiner Durchreicher vor die vorhandenen Dienste gesetzt — es ändert nichts, es protokolliert nur. Damit entsteht ohne Risiko das erste vollständige Bild, wer welche Schnittstelle wie stark nutzt. Im zweiten Schritt wandert die Authentifizierung ans Gateway, Dienst für Dienst; die alte Prüfung bleibt übergangsweise als zweite Verteidigungslinie aktiv. Erst danach folgen Limits, Quotas und Routing-Regeln. Wichtig ist dabei dieselbe Disziplin wie bei jeder Architekturänderung: additiv vorgehen, alte Wege erst abschalten, wenn der neue nachweislich trägt.
Am Ende steht ein Zustand, der sich im Alltag schlicht ruhiger anfühlt: ein Ort für Zugriffe, ein Ort für Schlüssel, ein Ort für Antworten auf die Frage „Wer war das?“. Und wenn der nächste Dienst dazukommt, bringt er keine neue Tür mit — er bekommt einen Eintrag am Eingang, der schon da ist.