I tried to cover this topic (what GraphQL Federation is and when to use it) on my page.

In short, when you have a big monolithic GraphQL API, every team has to contribute their domain in one language and one tech stack (framework). The deployment queue may get longer and it will have an impact on productivity (speed of iteration). Also, when everyone contribute to the same codebase, to the same GraphQL server, then there's a chance that a change with a performance regression slips through, or something that causes a runtime exception that may kill your server.

GraphQL federation helps you solve those issues. When you break down your monolithic GraphQL API into smaller parts, called subgraphs, each team work on their domain independently and deploy at their own pace.

Thanks to the process called schema composition, the integrity of those subgraphs is validated and their schemas are combined into one unified schema, the supergraph, this way the distributed system feels like a monolithic API to the end GraphQL consumer.