GraphQL Federation: Multi-Service Schemas
Introduction
When Netflix migrated from REST to GraphQL, they faced a problem: 40+ microservices, each owning different parts of the data model. A single monolithic GraphQL gateway wouldn’t scale. Their solution? GraphQL Federation—a pattern that lets independent services contribute to a unified schema while maintaining autonomy. Let’s explore how this architecture handles billions of requests daily.
The Schema Boundary Problem
Traditional GraphQL implementations use a single schema. This works until your User service needs to extend the Movie type with watchlist data, or your Recommendations service needs to add personalized scores to existing types. Federation solves this by letting services extend types they don’t own.
At Uber, each service defines its portion of the schema with the @key directive marking entities that other services can reference. The gateway discovers and merges these schemas automatically. When a query spans multiple services, the gateway orchestrates the execution plan—fetching base entities first, then resolving extended fields through entity references.
Entity Resolution and the _entities Query
The magic happens through entity resolution. When your query needs a User’s favoriteGenres field (owned by the Preferences service) alongside their email (owned by the Users service), the gateway first fetches the User entity, then calls the Preferences service’s special _entities resolver with the User’s ID.
Shopify’s implementation revealed a critical insight: naive entity resolution creates N+1 queries. Their gateway batches entity requests within 10ms windows, reducing database calls by 85%. The DataLoader pattern becomes essential at scale—without it, a query fetching 100 products with reviews would trigger 100 separate service calls instead of one batched request.
Query Planning and Execution Strategies
The gateway builds an execution plan by analyzing type ownership and field dependencies. Stripe’s federation gateway uses a two-phase approach: first, it constructs a dependency graph of which services own which fields; second, it parallelizes independent service calls while serializing dependent ones.
Consider a query fetching a user’s orders and recommended products. The gateway recognizes that orders and recommendations are independent, fetching them in parallel. But when the query asks for product reviews, the gateway must wait for product IDs before fetching reviews—this sequential dependency is unavoidable.
Schema Composition Conflicts
Airbnb discovered edge cases during federation migration. When two services define conflicting field types (User.age as Int vs String), composition fails. Their solution: establish schema governance with automated validation in CI/CD. Services must declare type extensions explicitly using extend type, and field types must match exactly across service boundaries.
Version skew poses another challenge. When the Users service deploys a schema change before dependent services update, queries break. LinkedIn solved this with schema registries that validate compatibility before deployment, rejecting changes that would break downstream consumers.
Performance and Caching Strategies
GitHub Link:
https://github.com/sysdr/sdir/tree/main/GraphQLFederation_Multi-ServiceSchemasDoorDash’s federation layer processes 50 million queries daily. They cache entity results at the gateway level with service-specific TTLs. User profiles cache for 60 seconds, while real-time delivery status bypasses caching entirely. The key insight: federation adds latency through service hops, so aggressive caching at entity boundaries becomes critical.
Query complexity analysis prevents abuse. GitHub’s federation gateway tracks resolver depth and breadth, rejecting queries exceeding cost budgets. Without this, a single malicious query could cascade across dozens of services, creating a distributed denial-of-service scenario.
The Build Exercise
The demo implements a three-service federation: Users service managing profiles, Products service handling catalog data, and Reviews service extending products with ratings. You’ll see the gateway discover schemas, merge them into a unified graph, and execute queries that span service boundaries. Watch how entity resolution batches requests and how the gateway parallelizes independent service calls.
Run ./demo.sh to launch the federation. The dashboard shows real-time query execution plans, service call patterns, and resolver timing. Try querying a user’s reviewed products—you’ll see the gateway orchestrate calls across all three services in under 50ms.
Federation transforms GraphQL from a single-service pattern into a true microservices architecture. The tradeoff? Increased complexity in query planning and latency management. But for organizations with dozens of services, it’s the only way to maintain schema coherence without sacrificing service autonomy.