GraphQL Federation: Microservices-APIs einheitlich orchestrieren

Warum GraphQL Federation die Antwort auf Microservices-Komplexität ist

Die Migration von monolithischen Backends zu Microservices hat in den letzten Jahren in deutschen Unternehmen stark zugenommen. CTOs und IT-Leiter stehen jedoch vor einer wiederkehrenden Herausforderung: Wie integriert man dutzende verteilte Services zu einer kohärenten API, ohne Frontend-Teams mit der Komplexität der Backend-Landschaft zu konfrontieren? Genau hier setzt GraphQL Federation an. Statt eines monolithischen GraphQL-Servers oder eines spröden API-Gateways entsteht ein verteiltes, aber einheitliches Datenmodell, das jede Service-Verantwortlichkeit respektiert.

In diesem Artikel zeigen wir, wie GraphQL Federation funktioniert, welche Architektur-Entscheidungen sich in der Praxis bewähren und worauf Sie bei der Implementierung mit Apollo Federation v2 achten müssen. Die Inhalte basieren auf realen Projekten mit deutschen Mittelständlern und Konzernen, in denen wir verteilte API-Landschaften konsolidiert haben.

Das Problem klassischer API-Komposition

Wer Microservices betreibt, kennt die typischen Lösungsansätze für die Service-Komposition: Backend-for-Frontend (BFF), API-Gateway-Aggregation oder ein zentraler GraphQL-Monolith. Jeder dieser Ansätze bringt Probleme mit sich:

• BFF-Muster: Führt zu Code-Duplikation pro Frontend-Kanal und erschwert konsistente Datenmodelle.
• API-Gateway: Löst Routing, aber keine semantische Komposition über Service-Grenzen hinweg.
• GraphQL-Monolith: Wird schnell zum Engpass und untergräbt die Vorteile der Microservices-Architektur durch zentrale Verantwortung.

Federation löst diese Probleme, indem mehrere unabhängige GraphQL-Subgraphen zu einem übergreifenden Supergraphen zusammengeführt werden. Jedes Team kann sein Schema autonom entwickeln und deployen, während Konsumenten eine einzige, konsistente API sehen.

Architektur einer Federation: Subgraphen, Router und Schema-Composition

Eine produktionsreife Federation-Architektur besteht aus drei Hauptkomponenten:

1. Subgraphen

Ein Subgraph ist ein eigenständiger GraphQL-Service, der einen Teil des Datenmodells exponiert. Für ein typisches E-Commerce-Szenario könnten Subgraphen wie folgt aussehen:

• products — Produktdaten, Kategorien, Preise
• users — Identität, Profile, Berechtigungen
• orders — Bestellungen, Status, Historie
• inventory — Lagerbestände, Verfügbarkeit

2. Router (Gateway)

Der Router empfängt eingehende Anfragen, plant Query-Ausführungen über mehrere Subgraphen hinweg und fügt die Antworten zusammen. Apollo Router (in Rust geschrieben) bietet hierfür exzellente Performance und ist für hochfrequentierte deutsche Plattformen mit DSGVO-konformen Logging-Optionen geeignet.

3. Schema Registry & Composition

Eine zentrale Schema-Registry überprüft, ob neue Subgraph-Versionen kompatibel sind, bevor sie deployed werden. Apollo GraphOS oder selbst gehostete Alternativen wie WunderGraph Cosmo ermöglichen diese Prüfung in CI/CD-Pipelines.

Praxisbeispiel: Entität über mehrere Subgraphen erweitern

Der Kern von Federation v2 ist die Fähigkeit, eine Entität in mehreren Subgraphen zu definieren und um zusätzliche Felder zu erweitern. Schauen wir uns ein konkretes Beispiel für eine Product-Entität an.

Im Products-Subgraphen definieren wir die Basisdaten:

extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.6",
        import: ["@key", "@shareable"])

type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Float!
  category: String!
}

Im Inventory-Subgraphen erweitern wir dieselbe Entität um Lagerinformationen:

extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.6",
        import: ["@key", "@external"])

type Product @key(fields: "id") {
  id: ID!
  stockLevel: Int!
  warehouseLocation: String!
  estimatedRestock: DateTime
}

Der Router stellt sicher, dass eine Query wie { product(id: "42") { name price stockLevel } } automatisch beide Subgraphen anspricht und die Ergebnisse zu einer einzigen Antwort zusammenführt. Für das Frontend bleibt diese Komplexität vollständig unsichtbar.

Performance-Optimierung mit Query-Planning

Ein häufiges Missverständnis: Federation wäre langsamer als ein monolithischer GraphQL-Server. In der Praxis ist das Gegenteil der Fall, sofern man drei Optimierungen umsetzt:

1. Query-Plan-Caching: Apollo Router cached den berechneten Ausführungsplan pro Query-Hash. Wiederholte Anfragen umgehen die Planungsphase komplett.
2. Entity-Batching mit DataLoader: Reduziert N+1-Probleme zwischen Subgraphen drastisch.
3. HTTP/2 Multiplexing: Subgraph-Aufrufe parallel über persistente Verbindungen ausführen.

In einem unserer Kundenprojekte konnten wir die p99-Latenz einer komplexen Produktseite von 850 ms auf 220 ms reduzieren, allein durch das Aktivieren von Query-Plan-Caching und entitätsbezogenem Batching.

Versionierung und Schema-Evolution ohne Breaking Changes

Eine der wichtigsten Disziplinen in Federation-Projekten ist die kontrollierte Schema-Evolution. Im Gegensatz zu REST-APIs, wo häufig URL-Pfade versioniert werden (/v1, /v2), setzt GraphQL auf evolutionäre Schemas. Folgende Best Practices haben sich bei deutschen Enterprise-Kunden bewährt:

• @deprecated nutzen: Felder werden zunächst als veraltet markiert, statt sie sofort zu entfernen.
• Schema-Checks in CI/CD: Jede Pull-Request prüft, ob Änderungen Konsumenten brechen.
• Operation-Tracking: Anhand von Telemetriedaten erkennen, welche Felder noch aktiv genutzt werden.
• Contract-Tests: Subgraph-Teams definieren Pact-ähnliche Verträge mit Konsumenten.

DSGVO-Konformität in einer Federation-Architektur

Für deutsche Unternehmen ist die DSGVO-Konformität kein optionales Feature. In einer Federation-Architektur sind drei Aspekte besonders wichtig:

Field-Level Authorization

Personenbezogene Daten dürfen nur an autorisierte Konsumenten ausgeliefert werden. Apollo Router unterstützt deklarative Autorisierung über @requiresScopes und @policy-Direktiven. Beispiel:

type User @key(fields: "id") {
  id: ID!
  email: String! @requiresScopes(scopes: [["user:read:pii"]])
  publicName: String!
}

Datenresidenz

Subgraphen können in unterschiedlichen Regionen deployed werden. So lassen sich beispielsweise PII-Subgraphen ausschließlich in EU-Rechenzentren (z. B. AWS Frankfurt eu-central-1) betreiben, während andere Services global verfügbar bleiben.

Audit-Logging

Federation Router schreibt strukturierte Logs aller Datenzugriffe. Mit OpenTelemetry-Integration lassen sich diese in DSGVO-konformen Logging-Lösungen wie Loki oder Elastic Cloud Frankfurt persistieren.

Migration von REST zu Federation: Schrittweise Strategie

Niemand sollte eine bestehende REST-Landschaft über Nacht ersetzen. Wir empfehlen ein fünfstufiges Vorgehen:

1. Schema-Discovery: Bestehende REST-Endpunkte analysieren und Domain-Boundaries identifizieren.
2. Erste Subgraphen aufbauen: Beginnen Sie mit einem nicht-kritischen Bounded Context, etwa „Produktkatalog“.
3. REST-Wrapper: Bestehende REST-APIs werden durch dünne GraphQL-Wrapper exponiert (Pattern: „Schema-First Wrapping“).
4. Frontend-Migration: Neue Features nutzen Federation, alte bleiben zunächst auf REST.
5. Konsolidierung: REST-Endpunkte werden schrittweise abgeschaltet, sobald keine Konsumenten mehr existieren.

Dieses Vorgehen verbindet sich gut mit dem Strangler-Fig-Pattern, das in unseren Legacy-Modernisierungsprojekten zum Einsatz kommt.

Tooling-Übersicht: Was Sie 2026 evaluieren sollten

• Apollo Federation v2.6+: Marktführer mit ausgereifter Toolchain.
• WunderGraph Cosmo: Open-Source-Alternative mit eigener Schema-Registry.
• Hive (The Guild): Cloud- oder Self-Hosted Schema-Registry mit gutem CI/CD-Tooling.
• GraphQL Mesh: Nützlich, um REST/SOAP/gRPC-Backends als Subgraphen zu virtualisieren.

Für deutsche Unternehmen mit hohen Compliance-Anforderungen empfehlen wir häufig die Kombination aus Apollo Router und einer self-hosted Hive-Instanz, da so keine Schema-Daten in fremde Clouds übertragen werden müssen.

Häufige Fallstricke und wie Sie sie vermeiden

In unseren Beratungsprojekten sehen wir immer wieder dieselben Probleme:

• Überföderation: Zu viele winzige Subgraphen erhöhen den Koordinationsaufwand. Halten Sie sich an Domain-Driven Design.
• Geteilte Entitäten ohne klare Ownership: Jede Entität braucht einen Owner-Subgraphen, der die Schlüsseldefinition vorgibt.
• Fehlendes Performance-Monitoring: Ohne OpenTelemetry-Tracing sind Performance-Probleme nicht diagnostizierbar.
• Direkter Subgraph-Zugriff: Konsumenten dürfen ausschließlich über den Router gehen, nie direkt auf Subgraphen.

Fazit: Federation als strategische Investition

GraphQL Federation ist kein Selbstzweck, sondern ein Werkzeug, um die Komplexität verteilter Systeme für Frontend-Teams zu kapseln. Richtig umgesetzt, beschleunigt sie die Produktentwicklung erheblich, weil neue Features ohne Backend-Koordination kombiniert werden können. Gleichzeitig entstehen klare Verantwortungsgrenzen zwischen Teams — ein Vorteil, den Conway’s Law in jeder Organisation belohnt.

Für deutsche Unternehmen bietet Federation zusätzlich die Möglichkeit, Datenresidenz-Anforderungen technisch sauber abzubilden und Compliance-Prüfungen zu vereinfachen. Wer heute in eine durchdachte API-Strategie investiert, schafft die Grundlage für KI-Integrationen, mobile Apps und Partner-Ecosysteme der nächsten Jahre.

Sie planen die Konsolidierung Ihrer API-Landschaft oder evaluieren GraphQL Federation für Ihr Unternehmen? Unser Team aus erfahrenen Architekten unterstützt Sie von der ersten Schema-Modellierung bis zum produktiven Rollout — Made in Germany, DSGVO-konform und mit nachweisbarer Erfahrung in Enterprise-Microservices.