Toda arquitetura distribuída que envelhece um pouco começa a parecer a mesma fotografia: uma parte do ecossistema expõe REST, outra decidiu adotar GraphQL na borda, alguns serviços internos usam gRPC e, em paralelo, filas e eventos foram entrando para resolver integrações assíncronas. Isoladamente, cada escolha faz sentido. O problema aparece quando ninguém mais consegue explicar por que cada uma delas existe.

É aí que nasce o Frankenstein arquitetural.

Não porque a arquitetura ficou híbrida. Arquitetura híbrida é absolutamente normal. O problema começa quando essa mistura acontece sem critério, sem linguagem comum e sem clareza sobre qual estilo de integração resolve qual tipo de problema.

Este artigo parte de uma posição bem direta: o debate maduro não é GraphQL versus REST, nem gRPC versus eventos. O debate maduro é este: que tipo de comunicação faz sentido neste contexto, para este consumidor, com este tipo de contrato, esta exigência de latência e este nível de maturidade operacional?

Porque, no fim das contas, o melhor protocolo não é o mais moderno. É o que resolve o problema certo sem aumentar o caos do sistema inteiro.

O erro não está na mistura, está na mistura sem lógica

Existe um vício comum em discussões de arquitetura: procurar a tecnologia “certa” como se ela fosse resolver o ecossistema todo. Isso costuma gerar perguntas pobres, como:

• Deveríamos migrar tudo para GraphQL?
• gRPC é melhor do que REST?
• Arquitetura madura precisa ser orientada a eventos?
• REST ficou ultrapassado?

Essas perguntas têm apelo de debate, mas pouco valor arquitetural.

Na prática, sistemas reais resolvem problemas diferentes ao mesmo tempo:

• consumo externo por parceiros
• dashboards e interfaces ricas
• comunicação interna entre serviços
• fluxos assíncronos e reativos
• integrações sensíveis a latência
• contratos fáceis de consumir por humanos e ferramentas

É natural que mais de um estilo de integração apareça no mesmo ecossistema.

O erro começa quando cada time escolhe a tecnologia com base em preferência local, hype ou conveniência pontual, sem considerar impacto no todo. O resultado é um ambiente em que cada interface fala um idioma diferente, a observabilidade fica fragmentada e qualquer troubleshooting exige entender cinco modelos mentais ao mesmo tempo.

Onde REST continua excelente

REST virou padrão por um motivo simples: em muitos cenários, ele continua sendo uma solução muito boa.

Quando existe um modelo de recurso razoavelmente claro, com operações previsíveis e sem grande necessidade de composição dinâmica, REST oferece várias vantagens que continuam relevantes:

• semântica HTTP bem conhecida
• tooling abundante
• boa ergonomia para APIs públicas
• facilidade de consumo por humanos e sistemas
• integração simples com cache, proxies e gateways
• baixo custo cognitivo para boa parte dos times

Para uma API pública de pedidos, por exemplo, algo assim ainda é totalmente defensável:

GET /customers/123/orders
GET /orders/9001
POST /orders


Esse estilo funciona especialmente bem quando:

• o consumidor externo espera previsibilidade
• o recurso é bem delimitado
• a composição de dados não é o problema central
• a simplicidade é mais valiosa do que a flexibilidade extrema

Há uma tentação, em certos círculos, de tratar REST como se fosse legado conceitual. Isso é um exagero. O que envelheceu mal, em muitos casos, não foi REST. Foram APIs mal desenhadas, mal versionadas ou usadas em contextos que pediam outra coisa.

REST continua forte quando o modelo de recurso continua forte.

Onde GraphQL realmente brilha

GraphQL entrou com mais força onde REST começou a gerar atrito no consumo, especialmente para interfaces que precisavam compor muitos dados de fontes diferentes.

O caso clássico continua válido: dashboards, páginas ricas, painéis administrativos, perfis complexos e experiências com múltiplos consumidores. Nessas situações, REST frequentemente força múltiplas chamadas ou devolve payloads rígidos demais. GraphQL melhora bastante isso porque orienta o contrato para o consumo.

Exemplo simples:

query Dashboard {
  customer(id: "123") {
    name
    orders {
      id
      total
      status
    }
    invoices {
      dueDate
      amount
    }
  }
}

A força do GraphQL está em alguns pontos bem claros:

• composição flexível de dados
• redução de overfetching e underfetching
• bom encaixe para múltiplos consumidores
• excelente como camada agregadora
• boa ergonomia para frontend-driven development

Mas aqui vale um cuidado importante: GraphQL não é substituto universal de REST.

Ele cobra preço em governança, modelagem de schema, autorização mais refinada, observabilidade e performance se o time não tratar o ecossistema com disciplina. Em outras palavras, GraphQL é poderoso quando resolve o problema certo. Fora disso, pode ser complexidade desnecessária.

GraphQL brilha quando a principal dor é composição dinâmica de dados. Não quando o objetivo é apenas parecer moderno.

Onde gRPC entra melhor

gRPC costuma aparecer com mais força onde o foco é comunicação interna entre serviços, baixa latência, contratos fortemente tipados e controle maior do ecossistema.

Em vez de pensar em gRPC como “REST mais rápido”, o mais útil é enxergá-lo como um estilo de comunicação especialmente bom para cenários service-to-service em ambientes controlados.

Exemplo simples em protobuf:

service PaymentService {
  rpc Authorize (PaymentRequest) returns (PaymentResponse);
}

Esse modelo tem vantagens muito fortes em alguns contextos:

• serialização binária eficiente
• tipagem mais rígida
• contratos bem definidos
• suporte forte a streaming
• excelente encaixe para comunicação interna
• bom desempenho em ambientes distribuídos

Só que gRPC também tem seus limites. Ele é menos natural para consumo humano direto, menos amigável para muitos cenários públicos e depende mais de um ecossistema interno controlado para entregar tudo o que promete.

Em termos práticos, gRPC costuma fazer mais sentido quando:

• a comunicação é majoritariamente interna
• latência e throughput importam bastante
• o time quer contratos mais rígidos
• existe maturidade operacional para lidar com isso

Tentar usar gRPC como solução genérica para tudo costuma gerar o mesmo erro conceitual de outras ondas arquiteturais: pegar uma tecnologia muito boa em um contexto específico e transformá-la em resposta universal.

Quando eventos fazem sentido de verdade

Arquitetura orientada a eventos tem um apelo forte porque parece sofisticada e moderna. Em muitos casos, ela realmente resolve problemas que comunicação síncrona resolve mal. O problema é quando eventos entram mais por encantamento do que por necessidade.

Eventos fazem muito sentido quando a necessidade principal é desacoplamento temporal.

Ou seja, quando uma parte do sistema precisa reagir a algo que aconteceu sem bloquear a transação original, sem depender de resposta imediata e sem impor sincronização excessiva entre produtores e consumidores.

Exemplo simples de evento de domínio:

{
  "event": "OrderPaid",
  "orderId": "123",
  "occurredAt": "2026-06-01T10:00:00Z"
}

 

Isso pode funcionar muito bem quando:

• outros contextos precisam reagir ao pagamento
• a reação pode acontecer de forma assíncrona
• o domínio tolera esse tipo de desacoplamento
• o modelo operacional já aceita reprocessamento, idempotência e consistência eventual

Mas é aqui que muita implementação escorrega. Eventos não são só “mensagens assíncronas legais”. Eles trazem custos importantes:

• observabilidade mais difícil
• tracing menos direto
• debugging mais complexo
• necessidade de replay e idempotência
• risco de contratos frágeis entre produtores e consumidores
• maior dificuldade para explicar o fluxo completo do negócio

Eventos valem muito a pena quando a assincronia é parte legítima do domínio. Fora disso, podem virar apenas complexidade disfarçada de modernidade.

O verdadeiro risco: arquitetura híbrida acidental

O problema central não está em coexistirem REST, GraphQL, gRPC e eventos. O problema está em essa convivência acontecer sem mapa, sem critério e sem linguagem comum.

É aqui que a arquitetura híbrida deixa de ser estratégia e vira acúmulo.

Alguns sintomas são bem claros:

• GraphQL foi adotado na borda, mas sem definição do que continua em REST
• alguns domínios usam gRPC, outros REST, outros mensagens, sem lógica evidente
• contratos foram evoluindo localmente sem padrão de ecossistema
• nenhum time consegue visualizar o mapa completo das integrações
• escolher tecnologia virou preferência de squad
• troubleshooting exige navegar por múltiplos protocolos sem padrão de observabilidade

Esse cenário é mais comum do que parece.

Uma empresa adota REST porque era o padrão inicial. Depois cria um BFF com GraphQL porque o frontend precisava compor dados. Em seguida, alguns times internos adotam gRPC por performance. Mais adiante, eventos entram para resolver integrações assíncronas. Tudo isso pode fazer sentido isoladamente.

Mas se ninguém define critérios de uso, o ecossistema começa a crescer como uma cidade sem urbanismo. Cada bairro resolveu seu problema local. O conjunto ficou difícil de habitar.

O que um time sênior deveria perguntar antes de escolher

Em vez de começar pela tecnologia, um time mais maduro deveria começar pelo contexto. Isso muda completamente a qualidade da decisão.

Aqui vai um framework simples, mas muito útil.

1. Quem consome essa interface?

Se o consumidor é externo, humano, parceiro ou terceiro, simplicidade e previsibilidade tendem a pesar mais. Se o consumidor é outro serviço interno, outras variáveis entram com mais força.

2. O principal problema é composição, performance, simplicidade ou desacoplamento?

Essa pergunta já elimina muita discussão vazia.

• Se o problema central é composição dinâmica de dados, GraphQL ganha força.
• Se o problema central é simplicidade de recurso, REST continua excelente.
• Se o problema central é comunicação interna eficiente e tipada, gRPC faz mais sentido.
• Se o problema central é reação assíncrona a eventos de domínio, eventos entram melhor.

3. A comunicação precisa ser síncrona?

Nem tudo precisa de resposta imediata. Mas nem tudo tolera assincronia.

Forçar eventos onde o domínio exige resposta imediata cria sofrimento. Forçar síncrono onde o domínio tolera reação posterior cria acoplamento desnecessário.

4. A organização consegue operar isso bem?

Essa talvez seja a pergunta mais negligenciada.

Não adianta escolher um estilo tecnicamente elegante se o time ainda não tem maturidade para observabilidade, governança de contrato, tracing, retries, replay, autorização ou troubleshooting naquele modelo.

5. A escolha melhora o ecossistema ou só resolve o problema local?

Arquitetura sênior olha para o sistema inteiro. Às vezes, a melhor decisão local piora o conjunto. Se a escolha aumenta demais o custo cognitivo do ecossistema, ela precisa ser repensada.

Um jeito maduro de combinar esses estilos

Uma arquitetura híbrida saudável poderia, por exemplo, seguir uma lógica assim:

• REST para APIs públicas e recursos bem definidos
• GraphQL na borda, em cenários de composição para frontend
• gRPC em comunicação interna que exige eficiência e contratos mais rígidos
• eventos para reações assíncronas entre contextos de negócio

Esse tipo de combinação faz sentido quando vem acompanhada de algo essencial: critérios claros de onde cada estilo entra, como os contratos são governados e como a observabilidade funciona por cima dessa diversidade.

Sem isso, a arquitetura híbrida vira apenas pluralidade sem coerência.

A senioridade aparece na coerência, não na quantidade de protocolos

Uma das maiores diferenças entre decisão técnica júnior e sênior é o foco.

A decisão mais imatura pergunta: “qual tecnologia é melhor?”

A decisão mais madura pergunta: “qual escolha resolve este problema sem piorar o sistema inteiro?”

No fim, o valor não está em usar REST, GraphQL, gRPC ou eventos. O valor está em construir um ecossistema em que cada um desses estilos tenha lugar, propósito e limite claros.

Senioridade em integração não se mede pela quantidade de protocolos que a empresa usa. Mede-se pela capacidade de explicar por que cada um deles existe.

Conclusão

REST, GraphQL, gRPC e eventos não são inimigos. São ferramentas diferentes para problemas diferentes.

O erro não está em combiná-los. O erro está em deixar que essa combinação aconteça sem critério, até que o ecossistema inteiro vire um Frankenstein arquitetural difícil de entender, difícil de operar e difícil de evoluir.

Arquitetura híbrida madura não é um mosaico acidental. É uma composição intencional.

E essa é a pergunta que mais importa para qualquer time sênior: estamos escolhendo estilos de integração com base no contexto, ou apenas acumulando decisões locais sem coerência sistêmica?

Mapeie os estilos de integração já usados na empresa e verifique se há coerência arquitetural ou apenas acúmulo histórico.