Ihr API-Gateway sitzt am Rand Ihrer Anwendungsumgebung. Hier geht der Traffic von mobilen Apps, Partner-Plattformen, internen Tools und anderen Services ein, bevor er die Backend-Systeme erreicht, die ihn verarbeiten. Lange Zeit war es sinnvoll, das über eine zentrale Stelle laufen zu lassen: Routing, Throttling, Authentifizierung und Observability kommen dann an einem einzigen Ort zusammen, betrieben von einem Team, unter einem Vertrag, den alle Service-Teams einhalten müssen.
Doch dann wächst Ihre Organisation vielleicht, und dasselbe Gateway fängt plötzlich an, Kosten zu verursachen, die nicht im Architekturdiagramm erscheinen. Das Traffic-Diagramm steigt, und mit ihm die Lizenzrechnung, weil das kommerzielle Modell pro Request abrechnet. Der Release-Kalender füllt sich, aber jede Änderung berührt dieselbe Konfiguration, sodass Änderungen in eine Warteschlange kommen. Eine falsch konfigurierte Route kann Endpoints von Teams lahmlegen, die sich noch nie begegnet sind. Das Plattform-Team, das den Gateway betreibt, wird zum Engpass und zum einzigen Team, das alle anderen entsperren kann.
Ab einem gewissen Massstab ist Gateway daher nicht länger ein Infrastrukturelement, sondern wird zum Koordinierungsproblem.
Das war der Punkt, an dem wir als Mimacom – im Einsatz für einen grossen Enterprise-Kunden, dessen Engineering-Organisation auf Dutzende Teams über mehrere AWS-Konten gewachsen war – entschieden, ihn auseinanderzunehmen.
Zentralisierung ist in Ordnung, solange fünf Services dahinter stehen. Sie wird kostspielig – finanziell und organisatorisch – wenn es plötzlich Dutzende sind, die von Teams betrieben werden, die in unterschiedlichen Taktfrequenzen deployen, in verschiedenen AWS-Konten, mit sehr unterschiedlichen Latenz- und Compliance-Profilen.
Drei Druckpunkte trieben uns zu einem dezentralisierten Modell:
Keines dieser Probleme ist ungewöhnlich. Sie treten in der Regel gemeinsam auf, und sie treten in der Regel etwa dann auf, wenn ein Team damit beginnt, quartalsweise Kapazitätsprüfungen für den Gateway selbst durchzuführen. Wenn Ihr zentraler Gateway in zu vielen Architektur-Reviews auftaucht, zahlen Sie diese Kosten wahrscheinlich bereits, ohne sie zu benennen.
Wir ersetzten den zentralen Gateway durch einen kleinen, wiederholbaren Baustein: einen AWS API Gateway plus einen Lambda Authorizer, als deploybares Terraform-Modul verpackt. Jedes Service-Team deployed eine Instanz in sein eigenes AWS-Konto, vor seinen eigenen Services. Sie besitzen die Routes, die Deployments und die Rechnung.
Diese Beschreibung ist leicht geschrieben und schwerer zu leben. Das Schwierige ist nicht das Deployen von Gateways; es geht darum sicherzustellen, dass die Konsistenz nicht zusammenbricht, sobald Sie den einzelnen gemeinsamen Gateway loslassen. Drei Design-Entscheidungen haben den Grossteil dieser Arbeit geleistet.
Routing und Rate-Limiting können pro Team variieren; Authentifizierung nicht. Jeder Gateway führt dieselbe Authorizer-Logik aus, die als Teil desselben Terraform-Moduls verteilt wird. Wenn ein Team das Modul konsumiert, erhält es das organisationsweite Auth-Verhalten kostenlos dazu. Es kann nicht versehentlich davon abweichen. Das ist der Hebel, der es dem Plattform-Team ermöglicht, die Kontrolle darüber zu lockern, wo Gateways betrieben werden, ohne die Kontrolle darüber zu verlieren, wie sie autorisieren.
Die Authorizer-Konfiguration wird vom zentralen Entwicklerportal als Kafka-Messages publiziert. Dazu gehört, welche Clients gültig sind, welche Scopes welchen APIs zugeordnet sind und welche Schlüssel rotiert wurden. Jeder Authorizer abonniert das Topic und aktualisiert seine In-Memory-Ansicht. Eine Scope-Änderung, die um 10:01 Uhr im Portal vorgenommen wird, ist innerhalb von Sekunden in jedem Gateway wirksam – ohne Deployment.
Das Portal bleibt die einzige Informationsquelle dafür, was die Policy ist; die Gateways sind lediglich die Orte, die sie durchsetzen. Governance muss keine zentralisierte Infrastruktur sein; sie kann ein zentralisierter Datenfluss über dezentralisierte Infrastruktur sein. Diese Unterscheidung ist der Kern des Ansatzes.
Kafka-Verfügbarkeit ist nicht die richtige Grundlage für Ihren Authentifizierungspfad. Dasselbe Authorizer-Modul akzeptiert eine beim Deployment eingebettete Konfiguration. Das ist in drei Situationen wichtig: Cold Starts, bei denen der Authorizer nicht auf ein Topic-Catch-Up warten sollte, bevor er seinen ersten Request bedient; Kafka-Ausfälle, bei denen der Authorizer weiterhin mit seiner zuletzt bekannten guten Konfiguration läuft, anstatt aus Gründen, die nichts mit Authentifizierung zu tun haben, abzubrechen; und Edge- oder eingeschränkte Umgebungen, in denen die Verbindung zum Entwicklerportal nicht verfügbar ist.
Das Portal ist im Steady State die Informationsquelle. Die eingebettete Konfiguration ist der Mindeststandard.
Es gibt zwei Builds des Authorizers. Die Rust-Variante bedient latenzempfindliche Pfade, bei denen jede Millisekunde Authorisierungs-Overhead in Produktmetriken oder Cold-Start-Empfindlichkeit sichtbar ist. Die TypeScript-Variante ist für Teams, deren APIs nicht auf dem Hot Path liegen und deren Ingenieure bereits mit Node vertraut sind. Beide konsumieren dieselbe Konfiguration und setzen dieselben Regeln durch. Die Wahl ist ein Ergonomie-vs.-Performance-Kompromiss, den das Team lokal trifft – keine Entscheidung, die das Plattform-Team für sie treffen muss.
Der Wandel ist an drei Momenten im Arbeitszyklus eines Teams am deutlichsten sichtbar:
Onboarding eines neuen Service. Früher bedeutete das Onboarding einer neuen API ein Ticket an das Plattform-Team, einen Review-Zyklus, eine Konfigurationsänderung im gemeinsamen Gateway und ein Deployment, das mit dem Release-Fenster aller anderen koordiniert werden musste. Jetzt ist es terraform apply gegen ein Modul, das das Team bereits kennt, mit einem Auth-Verhalten, über das sie nicht nachdenken müssen, weil es mit dem Modul geliefert wird. Onboarding wird zu einer Aufgabe eines einzelnen Teams statt eines Multi-Team-Koordinierungsproblems.
Rollout einer Auth-Änderung. Ein Scope, der unternehmensweit widerrufen werden musste, war früher ein koordiniertes Rollout: eine Änderung im zentralen Gateway, ein Zeitfenster, ein Deployment und eine Verifikationsrunde. Jetzt ist es eine Änderung im Entwicklerportal, die als Kafka-Event propagiert wird. Über Dutzende von Gateways hinweg ist die neue Policy innerhalb von Sekunden aktiv. Die Arbeit des Plattform-Teams hat sich einen Level nach oben verlagert. Sie betreiben nicht mehr den Gateway; sie besitzen das Modul, den Authorizer-Code und den Event-Vertrag.
Die Rechnung lesen. Da der Gateway jedes Teams in seinem Konto lebt, ist sein Traffic seine Kosten. Ein Team, das einen gesprächigen Client auf den Markt bringt und sein Request-Volumen verdreifacht, sieht die Kosten im selben Monat in seiner eigenen AWS-Rechnung. Dieses Signal landet bei den Personen, die darauf reagieren können – dem Team, das die API besitzt –, anstatt in einer Plattform-Position zu verschwinden, die niemand liest. Gleichzeitig entfiel die Traffic-bepreiste Lizenz des alten zentralen Gateways einfach; diese Kosten wurden nicht umverteilt, sie wurden eliminiert.
Dezentralisierung ist nicht kostenlos. Einige der Kompromisse sollten Sie zum Nachdenken anhalten:
Sie übernehmen eine Flotte. Sie betreiben nicht mehr einen Gateway; Sie betreiben Dutzende. Das Modul macht sie homogen, aber Observability, Versions-Rollout und End-to-End-Testing müssen für die Flotte konzipiert sein, nicht für die einzelne Instanz.
Das Kafka-Topic zwischen Entwicklerportal und Authorizern wird zu einer kritischen Abhängigkeit. Sein Schema, seine Retention und seine Replay-Semantik sind relevant. Der eingebettete Fallback mindert Ausfälle, ersetzt aber nicht die Notwendigkeit, diesen Vertrag sorgfältig zu betreiben.
Koordination verlagert sich, verschwindet aber nicht. Service-Teams koordinieren weniger mit dem Plattform-Team, aber mehr miteinander bei übergreifenden Belangen wie CORS-Policy, Fehlerformaten und Observability-Konventionen. Das Modul ist der Ort, an dem diese Konventionen leben. Es meinungsstark zu halten ist wertvoller als es flexibel zu halten.
Keiner dieser Punkte ist ein Grund, es nicht zu tun. Aber es sind Gründe, bewusst vorzugehen.
Für Ingenieure dreht sich die tägliche Veränderung um Eigenverantwortung und Reibung. Der Gateway ist nicht länger ein entferntes Infrastrukturelement, gegen das sie Tickets einreichen; er ist ein Modul in ihrem Repository. Sie können es lesen, lokal debuggen und über seine Fehlermodi nachdenken. Der Authorizer ist nur insofern eine Blackbox, als Teams nicht über ihn nachdenken müssen; sie können ihn bei Bedarf trotzdem lesen und debuggen.
Für Entscheidungsträger ist der wichtigere Wandel struktureller Natur. API-Kosten werden auf Team-Ebene lesbar, was es Engineering- und Produktführung ermöglicht, ehrliche Gespräche über Traffic, Wachstum und Unit Economics zu führen. Governance und Infrastruktur hören auch auf, gekoppelt zu sein: Das Entwicklerportal kann streng bleiben (ein Ort, eine Policy), während die Durchsetzungsinfrastruktur so breit skalieren kann, wie die Organisation es braucht. Das Plattform-Team wächst sublinear mit dem Rest des Engineerings. Es ist nicht mehr die Gatekeeping-Funktion für jeden neuen Service; stattdessen pflegt es das Modul, den Authorizer und den Event-Vertrag.
Dieser letzte Punkt ist der Ort, an dem das Skalieren in dieser Geschichte tatsächlich liegt. Hardware und Durchsatz skalieren einfach. Was nicht skaliert – in einer wachsenden Engineering-Organisation – ist der menschliche Koordinierungsaufwand jedes Infrastrukturelements, das alle Teams teilen müssen. Den Gateway zu dezentralisieren ist eine der saubersten Methoden, diesen Aufwand aus dem kritischen Pfad herauszunehmen.
Wenn Ihr zentraler API-Gateway öfter als gesund in Kapazitätsprüfungen, Lizenzverlängerungen oder Incident-Retrospektiven auftaucht, sind drei Massnahmen es wert, in Betracht gezogen zu werden.
Die wichtigste Massnahme ist die Entkopplung von Policy und Durchsetzung. Halten Sie das Entwicklerportal als Informationsquelle und lassen Sie Durchsetzungspunkte wachsen. Events sind ein besserer Verteilungsmechanismus für Policies als Tickets. Packen Sie den Gateway als Modul, nicht als Service, den das Plattform-Team betreibt: Ihr Produkt wird zum IaC, dem Authorizer und dem Update-Pfad, nicht zur laufenden Infrastruktur.
Kosten zu einem lokalen Signal zu machen ist die dritte Massnahme. Gateways in teamgebundenen Konten zu betreiben, macht API-Traffic zu einer Zahl, die das Team, das ihn erzeugt, tatsächlich sehen kann – statt einer Plattformposition, die niemand liest.
Die Form der Antwort ist unkompliziert. Die schwere Arbeit liegt in den Verträgen: der API des Moduls, dem Konfigurationsschema des Authorizers und dem Event-Fluss zwischen Entwicklerportal und Flotte. Wenn diese stimmen, folgt der Rest. Ob Sie einen Dezentralisierungsschritt abwägen, ein Entwicklerportal entwerfen oder neu überdenken, wie Policy Ihre Runtime erreicht – unsere Teams für DevOps und Platform Engineering und Cloud Engineering tauschen gerne ihre Erfahrungen aus.