What is GraphQL federation and when do you need it?
Assesses fundamental understanding of GraphQL conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Federation lets several teams own separate GraphQL subgraphs and compose them into one graph for clients. Each subgraph declares the entities it owns with a key directive, and a gateway or router plans and stitches queries across them.
type User @key(fields: "id") {
id: ID!
name: String!
}
When a query asks for User.name and User.orders, the router fetches the entity from the users subgraph and the orders subgraph and merges the results. Apollo Federation is the best-known implementation; schema stitching is an older, more manual alternative.
You need federation when a single monolithic schema becomes a bottleneck for multiple teams, or when services are owned independently. Costs include router complexity, extra network hops, careful entity key design and harder debugging. For a single team and a small schema, a modular monolith schema is simpler and faster.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.