GraphQL Federation Was Built Backwards

In a recent post , I wrote about the coordination bottleneck in GraphQL Federation and how schema changes that should take days can end up taking months, due to the overhead of finding the right people, aligning on design, and tracking work across subgraphs.

This post goes deeper into why that bottleneck exists.

It's a design flaw in how Federation was conceived.

Before we talk about Federation, let's revisit why GraphQL exists.

GraphQL was created to empower the API consumer. Instead of the server dictating what data you get, like REST endpoints do, the client describes what it needs:

No over-fetching. No under-fetching. The client is in control.

GraphQL starts from a simple idea: the API should be designed around what consumers need, not around how the backend happens to be structured.

Federation takes the GraphQL schema and splits it across teams. Each team owns a subgraph (a piece of the overall schema), and a composition process merges them into a supergraph.

Here's a simplified example. Team A owns users:

Team B owns orders:

Compose them, and you get a supergraph where a client can query users with their orders. This is the textbook example, and it works well.

Now let's see what happens when something needs to change.

A frontend team is building a new feature and needs to show whether a user is eligible for express shipping. The ideal query looks like this:

Simple enough. But where does shippingEligibility come from?

It doesn't exist in any subgraph. The User type is owned by Team A. Shipping logic lives in a fulfillment service maintained by Team C. The restrictions field depends on data from Team D's compliance service.

To add this field, the frontend team needs to:

1. Figure out that User is owned by Team A
2. Realize Team A can't provide shipping data
3. Find Team C, who owns fulfillment
4. Discover that restrictions requires Team D
5. Coordinate a design that works across all three subgraphs
6. Get the platform team to review the schema design
7. Wait for all three teams to implement their parts
8. Compose and verify the result

The frontend team started with a clear picture of what they needed. Federation forced them into a scavenger hunt across the organization to figure out who can build it and how.

This is the fundamental problem.

Federation's composition model works from the bottom up: subgraph teams build their schemas independently, and the supergraph is whatever comes out of the composition process.

The supergraph is a side effect. It's not designed. It's assembled.

GraphQL was designed to be consumer-first. If you take that seriously, the workflow should be the opposite:

Start with what the consumer needs. Design the supergraph to serve that. Then figure out how to distribute the work.

This is the insight behind what we call Fission.

Fission is a stateful schema graph engine that maintains two synchronized views of your federated graph: the supergraph (the consumer-facing API) and the subgraphs (what each team implements). The supergraph is the source of truth. When you make changes to it, Fission handles the consequences — propagating dependencies, managing entity keys, and keeping everything in sync.

Let's walk through the shipping example with Fission.

The frontend team describes what they need — their "dream query" :

This isn't a wish list. It's the starting point for API design.

On the Hub canvas, the team proposes the new fields directly on the supergraph:

At this point, nobody has decided which subgraph owns these fields. The design is purely about what the consumer needs. This is powerful because teams are not jumping to implementation too early. They avoid anchoring on a particular solution. All options stay open while the conversation focuses entirely on the API contract.

Now the architect assigns the new fields to subgraphs on the Hub canvas. Fission handles everything that follows:

• shippingEligibility on User is assigned to a fulfillment subgraph → Fission automatically propagates User @key(fields: "id") to that subgraph so the entity is resolvable
• expressAvailable and estimatedDays → Team C's fulfillment service will provide these
• restrictions → requires data from Team D's compliance service. Fission pulls in any transitive type dependencies automatically

The result is a concrete proposal: Team C needs to add ShippingEligibility to their subgraph, Team D needs to expose restrictions data, and composition will produce the supergraph the consumer asked for.

Hub routes the proposal to the right stakeholders automatically. Team A reviews because User is being extended. Team C reviews because they're implementing the new type. Team D reviews because their data is required.

Each team approves their part. Once approved, the work is assigned and tracked.

No scavenger hunt. No Slack threads. No platform team acting as a human switchboard.

The difference between composition and decomposition isn't just about workflow. It changes what gets built.

When you compose bottom-up, the supergraph reflects the backend's internal structure. Field names match service internals. Type boundaries align with team boundaries, not consumer use cases. The API is a mirror of the architecture, not a product designed for its users.

When you decompose top-down, the supergraph is designed for the consumer. Field names make sense from the client's perspective. Types are grouped by use case, not by which team happens to own the data. The API is a product.

This is the difference between an API that happens to work and an API that's designed to be used.

An important clarification: Fission and Federation are not competing concepts. They're complementary.

Federation handles runtime concerns: query planning, execution across subgraphs, entity resolution. It's the engine that makes a distributed graph work as a unified API.

Fission handles design-time concerns: how teams decide what the supergraph should look like, who is responsible for what, and how changes are proposed, reviewed, and tracked.

Federation is how you run a federated graph. Fission is how you evolve one.

Without Fission, Federation works fine at small scale — a handful of subgraphs, a few teams, informal coordination. But as the graph grows, the coordination overhead becomes the dominant cost.

That's where Fission and Hub come in.

If this sounds familiar, it should.

The shift from monoliths to microservices had the same tension. Monoliths are easy to design because everything is in one place. Microservices are powerful but introduce coordination overhead.

Federation is the microservices of API design. It gives you distributed ownership but makes coordinated change expensive.

Fission gives you the best of both: design like a monolith, implement as microservices.

You work with the supergraph as if it were a single schema. One coherent API designed for consumers. Then, Fission decomposes it into distributed responsibilities that map to your actual team structure.

We've been working with customers who manage large federated graphs, and the pattern is consistent.

1. Frontend team identifies a need
2. Weeks of meetings to find the right backend teams
3. Miro boards and design docs to propose schema changes
4. Platform team reviews for consistency
5. Each subgraph team implements independently
6. Composition breaks because of misaligned assumptions
7. More meetings to resolve conflicts
8. Eventually, the feature ships

1. Frontend team proposes the change on the Hub canvas
2. Affected teams are identified automatically
3. Stakeholders discuss and iterate on the proposal: comments, suggestions, and refinements happen in context
4. Once aligned, each team approves its part
5. Work is assigned and tracked in the proposal
6. Implementation proceeds with clear specifications
7. Composition succeeds because the design was validated upfront

The difference isn't incremental. It's structural.

Senior architects who've worked with Federation for years tell us this is a paradigm shift. Not because the technology is magic, but because it finally aligns the workflow with how API design should have worked from the start.

Fission was designed for human collaboration, but the model is inherently agent-friendly.

An AI agent building an application can describe its ideal query, explore the supergraph to see what exists, and propose changes for what's missing. A human reviews and approves. The agent implements.

This isn't science fiction. It's the natural extension of a top-down, consumer-first design model. When the consumer is an agent, having a structured, searchable graph with clear ownership is even more critical than when the consumer is a human.

But that's a topic for another post.

GraphQL was built to put the consumer first. The way Federation was originally conceived put the backend first.

Fission restores the original promise: start with what the consumer needs, then figure out how to build it.

It's not a replacement for Federation. It's the missing piece that makes Federation work the way it was always supposed to.

If you want to see Fission in action, watch the webinar or get in touch for a walkthrough.

Frequently Asked Questions (FAQ)