Recentemente, um novo desafio profissional me tirou da zona de conforto e me colocou diante de um problema que não era apenas técnico, mas estrutural: como escalar uma API GraphQL em um ambiente com múltiplos times, múltiplos domínios e deploys independentes.

Eu já conhecia o GraphQL, mas foi ao mergulhar em Federation que comecei a enxergar a diferença entre resolver o problema do cliente e resolver o problema da organização.

Este artigo não é sobre como usar GraphQL. É sobre o que acontece quando ele cresce demais.

O que é GraphQL (e por que ele foi revolucionário)

Criado pelo Facebook (hoje Meta) em 2015, o GraphQL surgiu para resolver limitações práticas das APIs REST:

• Overfetching
• Underfetching
• Multiplicidade de endpoints
• Evolução difícil de contrato

O diferencial do GraphQL é simples e poderoso: o cliente define exatamente os dados que precisa, em uma única requisição, com um schema fortemente tipado servindo como contrato.

Isso trouxe ganhos reais:

• Redução de payload
• Flexibilidade para múltiplos clientes (web, mobile, IoT)
• Evolução incremental de schema
• Documentação automática via introspection

Em projetos pequenos ou médios, um único servidor GraphQL central funciona muito bem.

O problema começa quando a empresa cresce.

O Limite do GraphQL Centralizado

GraphQL resolve o problema da comunicação cliente-servidor, mas ele não resolve automaticamente o problema organizacional.

Quando múltiplos times começam a alterar o mesmo schema, surgem sintomas claros.

1. Gargalo de Deploy

Em um schema centralizado:

• Todos os domínios vivem no mesmo repositório.
• Alterações geram conflitos frequentes.
• Pull requests começam a se bloquear.
• O pipeline de CI/CD vira gargalo compartilhado.

O efeito colateral é sutil, mas perigoso:

times passam a coordenar releases por causa da API.

Isso reduz autonomia e desacelera evolução.

2. Propriedade Indefinida do Schema

Quem é dono do tipo User?

• Se Pagamentos adiciona um campo que quebra Usuários, quem corrige?
• Se Crédito precisa alterar uma entidade base, precisa negociar com quantos times?

Sem ownership claro, o schema vira um território compartilhado sem fronteiras.

E territórios sem fronteiras geram conflitos.

3. Monólito de API (Mesmo com Microserviços)

Esse é um erro comum.

Você tem microserviços separados, mas cria um único servidor GraphQL que:

• Conhece todos os bancos
• Orquestra regras de negócio cruzadas
• Acessa múltiplos domínios diretamente

Na prática, você criou um monólito de API em cima de microserviços.

A complexidade volta a se concentrar em um único ponto.

4. Problemas de Versionamento de Schema

Em um schema único:

• Breaking changes exigem coordenação global.
• Depreciações demoram meses.
• Não existe versionamento isolado por domínio.

Qualquer alteração estrutural passa a ser um evento organizacional.

Isso não escala.

O que é GraphQL Federation?

A Federation foi popularizada pelo ecossistema Apollo como uma forma de dividir o schema em partes independentes chamadas subgraphs.

Cada subgraph:

• Possui seu próprio schema
• Possui seu próprio ciclo de deploy
• É responsável pelo seu domínio

O gateway compõe esses schemas em um supergraph único.

O ponto central da Federation não é dividir arquivos.

É distribuir responsabilidade.

Imagine três domínios:

• Contas
• Transações
• Crédito

O serviço de Contas define:

type User @key(fields: "id") {
id: ID!
name: String
balance: Float
}

O serviço de Crédito pode estender esse tipo:

extend type User @key(fields: "id") {
  id: ID! @external
  creditLimit: Float
}

O domínio de Crédito não precisa que Contas conheça seu modelo interno.
A dependência é declarativa e contratual.

Isso reduz acoplamento estrutural entre domínios.

Gateway vs Router: Uma Distinção Importante

Quando falamos em Federation, precisamos diferenciar duas implementações principais.

Apollo Gateway

• Implementado em Node.js
• Baseado em JavaScript
• Primeira geração de runtime federado
• Alta flexibilidade e fácil customização

Ele foi essencial para popularizar Federation.

Porém, possui limitações naturais do ambiente Node:

• Event loop único
• Garbage collection impactando latência
• Maior consumo de memória sob alta carga
• Performance limitada em cenários de alta concorrência

Para cargas moderadas, funciona bem.

Para escala massiva, começa a mostrar limites.

Apollo Router

O Apollo Router é uma reescrita completa em Rust.

Características técnicas relevantes:

• Compilado (não interpretado)
• Sem garbage collector
• Controle fino de concorrência
• Arquitetura orientada a streaming
• Melhor paralelização de chamadas a subgraphs

Na prática, isso significa:

• Latência menor (principalmente P95/P99)
• Melhor throughput
• Uso mais eficiente de CPU
• Menor consumo de memória

Em arquiteturas distribuídas, o gateway é o ponto mais crítico do sistema.

Ele está em todas as requisições.

Se ele degrada, todo o sistema degrada.

Por isso o Router se tornou a escolha padrão em ambientes de alta escala.

Query Planning: O Cérebro do Supergraph

O gateway não apenas encaminha requisições.

Ele constrói um plano de execução (query plan):

• Analisa a query do cliente
• Determina quais campos pertencem a cada subgraph
• Resolve dependências entre entidades
• Executa chamadas em paralelo sempre que possível

Esse planejamento é essencial para minimizar latência e reduzir chamadas desnecessárias entre serviços.

A eficiência do query planner é um dos fatores que diferencia implementações de gateway.

Acoplamento Entre Domínios

Sem Federation, domínios começam a vazar entre si:

• Crédito acessa diretamente o banco de Usuário
• Pagamentos depende de estrutura interna de Contas
• Resolvers centrais começam a concentrar lógica cruzada

Isso gera:

• Dependências circulares
• Dificuldade de refatoração
• Aumento da complexidade cognitiva

Federation força disciplina arquitetural:

• Cada domínio é responsável por seus dados
• Extensões são explícitas
• O contrato é validado na composição do supergraph

O acoplamento deixa de ser implícito e passa a ser formalizado.

Em resumo:

• GraphQL resolve o problema do cliente.
• Federation resolve o problema da organização.
• E o Router resolve o problema da escala.

Quando a API começa a refletir a estrutura da empresa, a arquitetura precisa evoluir junto. Federation não é apenas uma técnica de composição de schema. É um modelo arquitetural que permite autonomia, governança e escalabilidade organizacional.

O supergraph não é apenas uma evolução técnica, ele é um reflexo da maturidade do sistema e da organização que o construiu.