Forem: Kaue Campos

Do Monólito ao Supergraph: Como o GraphQL Federation Escala Microservices

Kaue Campos — Wed, 18 Feb 2026 14:02:15 +0000

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.

Como Melhorar o Desempenho de Aplicações Node.js com Clusterização

Kaue Campos — Thu, 31 Oct 2024 17:48:49 +0000

Um dos grandes dilemas para nós, desenvolvedores, é como oferecer a melhor performance para o usuário final. Queremos que nossos sistemas sejam ágeis, eficientes e menos propensos a falhas. Mas, em meio ao desenvolvimento, nem sempre percebemos algumas estratégias que podem fazer uma grande diferença nesse quesito.

Imagine o seguinte cenário: você tem uma aplicação hospedada em um cloud provider, como a AWS, utilizando uma instância EC2 para rodar uma API em Node.js. Tudo está funcionando bem, mas, com o aumento da carga, o servidor começa a apresentar limitações. Ele só consegue processar um certo número de requisições simultâneas, gerando lentidão e até falhas em horários de pico. Isso acontece porque, por padrão, o Node.js opera em um único thread, usando apenas um núcleo de CPU.

Aqui, muitos desenvolvedores podem pensar em escalar a aplicação horizontalmente, criando novas instâncias de servidor. No entanto, antes disso, uma alternativa poderosa e eficiente está à nossa disposição: a clusterização de processos em Node.js. Com essa técnica, conseguimos aproveitar ao máximo os recursos de CPU do servidor, criando um ambiente mais robusto e escalável, tudo sem precisar criar novas instâncias.

Tá, mas como funciona a clusterização afinal?

A clusterização é uma técnica que permite executar várias cópias de uma aplicação Node.js (chamadas de workers) em paralelo, dentro do mesmo servidor. Como o Node.js é, por natureza, um ambiente de execução single-threaded, ele usa apenas um núcleo de CPU por vez. Isso limita a capacidade de processamento, principalmente em servidores multicore, onde recursos estão ociosos enquanto a aplicação utiliza apenas um núcleo.

Através da clusterização, podemos criar múltiplos workers, cada um rodando uma instância separada da aplicação. Estes processos são gerenciados por um processo principal (ou mestre), que distribui as requisições entre os workers disponíveis. Cada worker pode ser alocado em um núcleo de CPU diferente, permitindo que a aplicação use todos os núcleos da máquina, distribuindo a carga de trabalho e aumentando significativamente o desempenho.

Imagine que você tenha um servidor com 4 núcleos de CPU e que, sem clusterização, sua aplicação usa apenas um deles. Ao clusterizar a aplicação, podemos criar 4 workers, cada um em um núcleo. Isso quer dizer que, em vez de processar, por exemplo, 100 requisições por segundo, ela poderia processar até 400, com uma carga mais bem distribuída e menor tempo de resposta.

Outro benefício importante é a resiliência. Com vários processos rodando, se um worker falha, o processo principal pode reiniciar apenas o worker afetado, sem derrubar toda a aplicação. Isso resulta em uma aplicação mais estável e menos sujeita a períodos de inatividade. Além disso, como todos os workers compartilham o mesmo servidor, eles acessam os mesmos recursos (como a memória e o sistema de arquivos), o que reduz a necessidade de escalonamento horizontal imediato (como a criação de novas instâncias de servidor) e diminui os custos.

Conclusão

A clusterização de processos em Node.js é uma estratégia poderosa que pode transformar o desempenho das suas aplicações, especialmente em ambientes de produção onde a carga de trabalho pode ser imprevisível. Ao implementar múltiplos workers, você não só melhora a capacidade de resposta e a escalabilidade da sua aplicação, mas também a torna mais resiliente a falhas. Isso significa que sua aplicação pode aproveitar ao máximo os recursos de CPU disponíveis, permitindo que atenda a um número maior de requisições simultâneas de forma eficiente.

Se você está curioso para aprender mais sobre como implementar a clusterização em suas aplicações Node.js, eu recomendo dar uma olhada neste artigo que explico sobre Criando Clusterização em Aplicações Node.js. É uma excelente maneira de começar a otimizar sua aplicação e proporcionar uma experiência ainda melhor para suas apis!

Criando Clusterização em Aplicações Node.js

Kaue Campos — Thu, 31 Oct 2024 17:39:18 +0000

O Node.js é uma plataforma popular para desenvolver aplicações escaláveis, mas sua arquitetura de thread única pode se tornar um gargalo em situações de alta carga. Para aproveitar ao máximo o poder do Node.js, a clusterização é uma técnica eficaz que permite utilizar múltiplos núcleos de CPU, melhorando o desempenho e a capacidade de resposta da sua aplicação.

Pré-requisitos

Node.js instalado na sua máquina. Você pode baixar a versão mais recente em nodejs.
Familiaridade básica com JavaScript e Node.js.

Passo 1: Criar um Novo Projeto Node.js

Primeiro, crie um novo diretório para o seu projeto e inicie um novo projeto Node.js:

mkdir node-cluster

cd node-cluster

npm init -y

Passo 2: Instalar Dependências

Para este tutorial, você precisará apenas do próprio Node.js, mas vamos usar o express para criar um servidor HTTP simples. Instale o express com o seguinte comando:

npm install express

Passo 3: Criar o Servidor com Clusterização

Crie um arquivo chamado server.js e adicione o seguinte código:

const cluster = require('cluster');
const express = require('express');
const http = require('http');
const os = require('os');

const app = express();
const numCPUs = os.cpus().length;

// Middleware para simular processamento intenso
app.get('/', (req, res) => {
  let sum = 0;
  for (let i = 0; i < 1e7; i++) {
    sum += i;
  }
  res.send(`Soma: ${sum}, Processado pelo Worker: ${process.pid}`);
});

// Lógica de clusterização
if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Cria um worker para cada núcleo de CPU
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} morreu`);
  });
} else {
  // Cada worker escuta na mesma porta
  const server = http.createServer(app);
  server.listen(3000, () => {
    console.log(`Worker ${process.pid} started`);
  });
}

A configuração do cluster deve ser feita de acordo com a quantidade de CPUs disponíveis em sua máquina ou servidor. Por exemplo, se o seu servidor possui 6 CPUs, é ideal criar 6 workers para aproveitar ao máximo os recursos disponíveis. Utilizar mais workers do que núcleos de CPU pode levar a uma sobrecarga e diminuir o desempenho, enquanto usar menos workers pode resultar em subutilização dos recursos. É recomendável testar diferentes configurações para encontrar o equilíbrio ideal entre desempenho e utilização de recursos.

Passo 4: Executar a Aplicação

Agora você pode executar sua aplicação. Use o seguinte comando:

node server.js

Caso siga o exemplo voce verá em seu terminal algo semelheate a:

Master 12345 is running
Worker 12346 started
Worker 12347 started
Worker 12348 started

Passo 5: Teste a Aplicação

Para testar a rota / do seu servidor local utilizando curl, você pode usar o seguinte comando:

curl http://localhost:3000/

Ao executar o comando acima no terminal, você deve receber uma resposta similar a esta:

Soma: 49999995000000, Processado pelo Worker: 12348