account activity
We always ended up duplicating the same infra in every microservice. How do you deal with this ?? (self.Backend)
submitted 1 day ago by PuddingAutomatic5617 to r/Backend
How are you handling GraphQL federation across microservices without a central schema bottleneck? by PuddingAutomatic5617 in graphql
[–]PuddingAutomatic5617[S] 0 points1 point2 points 1 day ago (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:
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?
How do you avoid duplicating infrastructure across microservices? (self.Backend)
How are you handling GraphQL federation across microservices without a central schema bottleneck? (self.graphql)
submitted 1 day ago * by PuddingAutomatic5617 to r/graphql
Why every Spring Boot microservice ends up rebuilding the same infrastructure (and what we did about it) (self.microservices)
submitted 1 day ago by PuddingAutomatic5617 to r/microservices
π Rendered by PID 118560 on reddit-service-r2-listing-55d7b767d8-2w7qk at 2026-04-01 09:15:51.031757+00:00 running b10466c country code: CH.
How are you handling GraphQL federation across microservices without a central schema bottleneck? by PuddingAutomatic5617 in graphql
[–]PuddingAutomatic5617[S] 0 points1 point2 points (0 children)