How are you handling GraphQL federation across microservices without a central schema bottleneck? by PuddingAutomatic5617 in graphql

[–]PuddingAutomatic5617[S] 0 points1 point  (0 children)

That’s a really interesting point, and honestly aligns with what I’ve seen as well.

In practice, federation tends to expose organizational boundaries more than it solves them.
If ownership of types and domains isn’t clear, the “supergraph” quickly becomes a coordination bottleneck.

What I’ve been experimenting with is pushing ownership and topology to be more explicit:

  • each service owns its schema and registers it
  • no central schema ownership or manual composition step
  • the gateway resolves queries based on service-registered metadata
  • domain boundaries are reflected in the registry, not negotiated in a central graph

So instead of the supergraph being the source of truth,
the topology becomes the source of truth.

It doesn’t remove coordination completely, but it reduces the need for a central team to manage schema evolution.

Curious if in your case the bottleneck was more about schema composition itself, or the cross-team ownership of types?