Why federation scales GraphQL - Visual Breakdown

Concept Flow - Why federation scales GraphQL

Client sends query

↓

Gateway receives query

↓

Gateway splits query by service

↓

Send subqueries to respective services

↓

Services resolve subqueries

↓

Gateway collects and merges responses

↓

Gateway returns combined result to client

The gateway breaks a big query into smaller parts, sends them to different services, then merges results to handle large GraphQL schemas efficiently.

Execution Sample

GraphQL

query {
  user(id: "1") {
    name
    reviews {
      product {
        name
      }
    }
  }
}

A client requests user info and their product reviews, which the gateway splits and sends to user and review services.

Execution Table

Step	Action	Service	Query Part	Response	Gateway State
1	Receive full query	Gateway	Full query	N/A	Holds full query
2	Split query	Gateway	user(id: "1") { name }	N/A	Prepares user subquery
3	Split query	Gateway	user(id: "1") { reviews { product { name } } }	N/A	Prepares review subquery
4	Send subquery	User Service	user(id: "1") { name }	{"user": {"name": "Alice"}}	Waiting for review response
5	Send subquery	Review Service	user(id: "1") { reviews { product { name } } }	{"reviews": [{"product": {"name": "Book"}}]}	Has user and review data
6	Merge responses	Gateway	N/A	Combined user and reviews data	Ready to respond
7	Return combined result	Gateway	N/A	{"user": {"name": "Alice", "reviews": [{"product": {"name": "Book"}}]}}	Query complete

💡 All subqueries resolved and merged, gateway returns full response to client

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
fullQuery	Full client query	Full client query	Full client query	Full client query	Full client query
userSubquery	N/A	user(id: "1") { name }	Sent to User Service	Received user data	Merged in final response
reviewSubquery	N/A	user(id: "1") { reviews { product { name } } }	Waiting	Sent to Review Service	Merged in final response
responses	Empty	Empty	{"user": {"name": "Alice"}}	{"user": {"name": "Alice"}, "reviews": [{"product": {"name": "Book"}}]}	Complete combined data

Key Moments - 3 Insights

Why does the gateway split the query instead of sending it whole to one service?

Because each service owns part of the schema, splitting lets each service handle only its data, improving scalability and separation (see execution_table steps 2 and 3).

How does the gateway know how to merge responses correctly?

The gateway uses the schema federation metadata to combine fields from different services into one response, as shown in step 6 where responses are merged.

What happens if one service is slow or fails?

The gateway waits for all subqueries; if one is slow, the whole query response is delayed. Federation allows independent scaling to reduce such delays.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the gateway send the user subquery to the User Service?

A Step 4

B Step 2

C Step 5

D Step 6

💡 Hint

Check the 'Action' and 'Service' columns in execution_table rows

According to variable_tracker, what is the state of 'responses' after Step 5?

A Empty

B Contains only user data

C Contains user and review data

D Merged final response

💡 Hint

Look at the 'responses' row under 'After Step 5' column

If the gateway did not split the query, what would likely happen?

A The query would be faster because it's sent once

B One service would handle the entire query, reducing scalability

C The gateway would merge responses from multiple services

D The client would receive partial data only

💡 Hint

Refer to key_moments explanation about query splitting and service ownership

Concept Snapshot

GraphQL federation splits a big query into smaller parts.
Each part goes to the service owning that data.
Services resolve their parts independently.
Gateway merges all responses into one.
This lets GraphQL scale by dividing work across services.

Full Transcript

In GraphQL federation, a client sends a query to a gateway. The gateway breaks the query into smaller subqueries based on which service owns which part of the schema. It sends these subqueries to the respective services. Each service resolves its part and returns data. The gateway collects all responses and merges them into a single response for the client. This approach allows GraphQL to scale by distributing query resolution across multiple services, improving performance and maintainability.

Practice

1. What is the main benefit of using GraphQL federation in a large project?

easy

A. It removes the need for any backend services.

B. It makes the API slower by adding more layers.

C. It splits a big API into smaller parts for easier management.

D. It forces all teams to work on the same codebase.

Solution

1. Step 1: Understand federation purpose

   Federation breaks a large GraphQL API into smaller, manageable services.

2. Step 2: Identify the benefit

   This splitting helps teams work independently and manage parts easily.

3. Final Answer:

   It splits a big API into smaller parts for easier management. -> Option C

4. Quick Check:

   Federation = splits API for management [OK]

Hint: Federation means splitting big API into smaller parts [OK]

Common Mistakes:

• Thinking federation slows down the API
• Believing federation removes backend services
• Assuming all teams share one codebase

2. Which of the following is the correct way to define a federated service in GraphQL SDL?

easy

A. type Query { product(id: ID!): Product }

B. extend type Query { product(id: ID!): Product }

C. service Query { product(id: ID!): Product }

D. federation type Query { product(id: ID!): Product }

Solution

1. Step 1: Recall federation SDL syntax

   Federated services use extend type to add fields to shared types.

2. Step 2: Match correct syntax

   extend type Query { product(id: ID!): Product } uses extend type Query, which is correct for federation.

3. Final Answer:

   extend type Query { product(id: ID!): Product } -> Option B

4. Quick Check:

   Federation uses 'extend type' syntax [OK]

Hint: Federation adds fields with 'extend type' [OK]

Common Mistakes:

• Using 'type' instead of 'extend type' in federated services
• Using non-existent 'service' or 'federation' keywords
• Confusing base schema with extended schema

3. Given two federated services: Product service defines type Product { id: ID!, name: String } and Review service extends it with extend type Product { reviews: [Review] }. What will a query for { product(id: "1") { name reviews { body } } } return?

medium

A. Product name and list of reviews with their body fields.

B. Only product name, reviews field will be null.

C. Error because reviews field is not defined in Product service.

D. Empty result because federated services cannot combine fields.

Solution

1. Step 1: Understand federation field extension

   The Review service extends Product with reviews, so combined schema includes reviews.

2. Step 2: Query result combines data

   The query asks for product name and reviews body, which federation resolves from both services.

3. Final Answer:

   Product name and list of reviews with their body fields. -> Option A

4. Quick Check:

   Federation merges fields, query returns combined data [OK]

Hint: Federation merges extended fields into one response [OK]

Common Mistakes:

• Assuming extended fields are unavailable
• Expecting errors due to field extension
• Thinking federated services cannot combine data

4. A federated GraphQL setup has two services: User and Order. The User service defines type User { id: ID!, name: String }. The Order service tries to extend User with extend type User { orders: [Order] } but the gateway returns an error. What is the likely cause?

medium

A. User type is not marked with @key directive in User service.

B. Order service must define User type fully, not extend it.

C. Gateway does not support federation.

D. Orders field must be defined in User service, not Order service.

Solution

1. Step 1: Check federation key requirement

   Federation requires types extended across services to have a @key directive for identification.

2. Step 2: Identify missing @key

   User type lacks @key in User service, so gateway cannot resolve extensions.

3. Final Answer:

   User type is not marked with @key directive in User service. -> Option A

4. Quick Check:

   @key missing causes federation errors [OK]

Hint: Missing @key on base type breaks federation [OK]

Common Mistakes:

• Thinking extended types must be fully redefined
• Blaming gateway instead of schema directives
• Assuming fields must be in base service only

5. In a large company, multiple teams manage different parts of a GraphQL API using federation. Which of these practices best helps federation scale effectively?

hard

A. One team manages all services to ensure consistency.

B. All teams edit the same schema file to avoid conflicts.

C. Teams avoid using @key directives to keep schemas simple.

D. Each team owns a service with clear @key types and minimal overlap.

Solution

1. Step 1: Understand federation team ownership

   Federation scales by letting teams own services with clear boundaries and keys.

2. Step 2: Identify best practice

   Clear @key types and minimal overlap avoid conflicts and enable smooth composition.

3. Final Answer:

   Each team owns a service with clear @key types and minimal overlap. -> Option D

4. Quick Check:

   Team ownership + @key = scalable federation [OK]

Hint: Clear ownership and @key enable smooth federation scaling [OK]

Common Mistakes:

• Thinking one schema file for all teams scales well
• Avoiding @key directives breaks federation
• Centralizing all services under one team limits scaling