Federated GraphQL schemas in a microservice-based architecture allow different services to define their own part of the schema, enabling a scalable and modular approach that aligns well with microservice principles. By giving clients access to a single API gateway, this federation increases API usability and development efficiency. However, challenges include maintaining schema consistency across services, handling cross-cutting concerns like authorization and error handling, and ensuring efficient query execution without incurring significant inter-service communication overhead.

Difficulty: 8/10

Topics: schema stitching, resolving conflicts, gateway performance

Scenario Questions

0-2 years experience

1
You’re adding a new field to a user profile in your service, but another team already has a field with the same name—how do you avoid a schema collision when using federated GraphQL?
2
Your team’s GraphQL gateway starts returning 500 errors after you deployed a new service—what’s the first thing you check in a federated setup?
3
A client query is failing because it’s asking for a field that exists in two services—how do you figure out which one is causing the issue?

2-5 years experience

1
A feature team added a new type to their service that conflicts with an existing type in another service—how do you debug and resolve this without blocking their launch?
2
Users are reporting slow load times on the homepage after federating the product catalog service—what could be causing the latency, and how would you fix it?
3
Your team owns the user service in a federated schema, but other teams keep adding fields to it without coordination—how do you enforce ownership and prevent schema sprawl?

5-8 years experience

1
You’re designing a federated GraphQL gateway that serves 10K+ QPS—what caching, batching, or query planning strategies do you implement to avoid becoming a bottleneck?
2
How would you design a rollout strategy for a breaking schema change in a federated system where 50+ services depend on it, without causing client downtime?
3
Two teams are defining the same entity (e.g., Order) with different fields and resolvers—how do you architect a solution that allows both to evolve independently while maintaining query consistency?

8+ years experience

1
You’re migrating from a monolithic GraphQL API to a federated model across 100+ microservices—how do you prioritize which services to federate first, and how do you handle legacy clients during the transition?
2
How would you design a governance model for federated schemas that prevents teams from introducing performance anti-patterns or naming collisions at scale, while still enabling autonomy?
3
A critical service in your federated graph is owned by an external vendor—how do you ensure reliability, versioning, and backward compatibility when you have no control over their schema changes?

Follow-up Questions

❓How do you handle a field that exists in two services with different types?
❓What happens when one service’s schema changes and breaks a client query?
❓How would you monitor and alert on gateway errors in a federated setup?