Why federation scales GraphQL - Performance Analysis
When using GraphQL with federation, we want to understand how the time to get data changes as the number of services grows.
We ask: How does combining multiple GraphQL services affect the speed of queries?
Analyze the time complexity of this federated GraphQL query resolver snippet.
type Query {
product(id: ID!): Product
}
type Product @key(fields: "id") {
id: ID!
name: String
price: Float
}
extend type Review @key(fields: "id") {
id: ID! @external
product: Product @requires(fields: "id")
}
This code shows how a federated GraphQL schema splits data across services and links them by keys.
Look for repeated data fetching or combining steps.
- Primary operation: Fetching data from each subservice for parts of the query.
- How many times: Once per service involved in the query, plus merging results.
As the number of federated services (n) increases, the query engine calls each service once to get its data.
| Number of Services (n) | Approx. Operations |
|---|---|
| 2 | 2 service calls + 1 merge |
| 5 | 5 service calls + 1 merge |
| 10 | 10 service calls + 1 merge |
Pattern observation: Operations grow roughly linearly with the number of services.
Time Complexity: O(n)
This means the time to resolve a federated query grows linearly with the number of services involved.
[X] Wrong: "Federation makes queries slower exponentially because it combines many services."
[OK] Correct: Each service is called once per query, so the growth is linear, not exponential.
Understanding how federation scales helps you design systems that stay fast as they grow, a key skill in real projects.
What if the query requested nested data requiring multiple calls per service? How would that affect the time complexity?