Toward Federated GraphQL

Day 4 left Netflix with many Backend-for-Frontend services, each fanning out to an ever-larger mesh of microservices, each re-implementing similar "call these services, stitch the results" logic. As the service count kept climbing, two needs collided: clients still wanted data tailored precisely to each screen (the Day 3 promise), but Netflix no longer wanted a shared platform where everyone's code shared runtime fate (the Day 4 pain). GraphQL, and specifically GraphQL Federation, is how Netflix resolved that collision.

GraphQL is a query language and runtime for APIs, originally from Facebook, in which the client asks for exactly the fields it wants — across related objects — in a single request, and the server returns precisely that shape. It stands in contrast to REST (Day 2), where the server dictates fixed response shapes per endpoint.

The pieces you need:

• Schema — a strongly-typed description of every object the API exposes and how objects relate. It is the contract; both clients and tooling read it.
• A single endpoint that accepts a query describing the exact tree of data the client wants.

query {
  user(id: "42") {
    name
    continueWatching {
      title
      progress
    }
  }
}

The response mirrors that query one-to-one: a user with a name and a list of continueWatching items, each with title and progress — nothing more, nothing less, in one round trip. This is the same tailoring goal experience APIs pursued, but expressed declaratively by the client instead of imperatively by a server-side adapter.

A first instinct is to build one GraphQL schema for all of Netflix and put one team in charge of it. But that recreates the Day 2 bottleneck: one central schema, one gatekeeping team, everyone waiting. It also recreates the Day 4 coupling if that one graph runs as one shared service. Federation is the design that avoids both.

Two more terms:

• Subgraph — a piece of the overall schema, owned, implemented, and deployed by one team, covering the types and fields that team is responsible for (the "titles" subgraph, the "user" subgraph, the "viewing history" subgraph).
• Gateway — a routing layer that composes the many subgraphs into one unified schema, and at query time splits an incoming query across the relevant subgraphs and stitches their results back together.

GraphQL Federation is the arrangement where many independently-owned subgraphs are composed by a gateway into a single graph that clients see as one API. Netflix built this on its DGS framework (Domain Graph Service, its open-sourced GraphQL server framework) as part of an initiative it has described publicly under the name Studio Edge.

The client sends one query for a whole screen. The gateway figures out which subgraph owns each requested field, dispatches sub-queries to those subgraphs concurrently, and assembles one response. To the client it is a single graph; behind the gateway it is many teams' services.

This is the payoff, and it is worth stating as a direct answer to each earlier day's problem.

• Tailored data — like experience APIs, but declarative. Clients ask for exactly the fields each screen needs in one request, so the chattiness of OSFA REST (Day 2) and the manual server-side stitching of experience APIs (Day 3) both go away. The client, not a hand-written adapter, specifies the shape.
• No operational coupling — unlike the shared platform. Each team owns and deploys its own subgraph as its own service (Day 4's fix, generalized). One team's subgraph can be released, scaled, and fail on its own, without a shared platform where everyone's code runs in one process. Velocity and isolation.
• No central bottleneck — unlike OSFA. A team adds or changes fields in its own subgraph and the composed graph gains them, with no single API team gatekeeping every change (Day 2's bottleneck, dissolved).

In one sentence: federated GraphQL gives clients the tailoring of experience APIs with the isolation and ownership of BFFs, unified behind one graph.

The diagram makes the resolution literal: the two properties that traded against each other in every earlier chapter — tailored responses and per-team isolation/ownership — are, for the first time, both satisfied by one design.

Because each day was meant to stand alone, here is the whole arc in one place — each stage in a line, with its win and its unsolved problem.

Read top to bottom, each row's "left unsolved" is the reason the next row exists. That is the whole point of the "unusual evolution": Netflix did not zig-zag randomly — each step deliberately paid down the previous step's debt, and incurred a new, smaller one.

Consistent with every other day: GraphQL Federation buys its benefits with new costs, and a senior engineer names them.

• Gateway complexity. The gateway that composes subgraphs and splits queries is itself critical infrastructure — it must be fast, highly available, and carefully operated, because every client query flows through it.
• Schema governance. Many teams sharing one composed graph means the schema needs conventions, review, and coordination so that independently-evolved subgraphs still fit together cleanly.
• Cross-subgraph performance. A query that spans several subgraphs can reintroduce fan-out and the N+1 pattern behind the gateway, so batching and careful resolver design still matter.

None of these undo the win. They are the reason the story does not end here — the same way OSFA, experience APIs, and BFFs each had a "left unsolved" column. Architecture is a sequence of deliberate trades, and Netflix's API history is one of the clearest worked examples of that truth.

• Netflix adopted GraphQL — a query language where the client asks for exactly the fields it needs from a single graph in one request — and specifically GraphQL Federation.
• Core vocabulary: schema (the typed contract), subgraph (a slice of the schema owned and deployed by one team), gateway (composes subgraphs into one graph and routes queries), federation (the whole arrangement).
• Netflix built this on its DGS framework (open-sourced) as part of the Studio Edge initiative.
• Federation resolves the arc's tensions: clients get tailored data like experience APIs, but each team owns and deploys its own subgraph, so there is no shared-platform operational coupling and no central API-team bottleneck.
• The full arc: OSFA REST (server-shaped, chatty, bottlenecked) → experience APIs (adapter-shaped, coupled) → BFFs (isolated but sprawling) → federated GraphQL (declarative, isolated, unified) — each step pays down the previous step's debt.
• Federation is not free: gateway complexity, schema governance, and cross-subgraph performance are its new costs — proving again that architecture is a sequence of deliberate tradeoffs.

• [ ] I can define GraphQL and contrast it with REST on who shapes the response.
• [ ] I can define schema, subgraph, gateway, and federation in my own words.
• [ ] I can explain how a single client query gets split across subgraphs and stitched back by the gateway.
• [ ] I can say, for each earlier chapter (OSFA, experience APIs, BFFs), what federation improves on.
• [ ] I can explain how federation delivers experience-API tailoring without the shared-platform operational coupling.
• [ ] I can name federation's own costs (gateway complexity, schema governance, cross-subgraph performance).
• [ ] I can retell the whole Netflix API arc as a chain where each step pays down the previous step's tradeoff.