RESUMO
A adoção crescente de arquiteturas de microsserviços trouxe à tona limitações concretas do modelo REST sobre HTTP/1.1, protocolo que dominou a integração de aplicações web por décadas. Serialização em JSON, ausência de multiplexação nativa e cabeçalhos verbosos representam gargalos reais em sistemas de alto volume. O gRPC, framework open source desenvolvido pelo Google, propõe uma alternativa fundamentada em HTTP/2 e Protocol Buffers: serialização binária compacta, multiplexação de requisições em conexão única e contratos de interface estritamente tipados em arquivos .proto. Este trabalho analisa o gRPC sob a perspectiva de arquitetura de software, comparando-o ao REST em termos de eficiência de serialização, suporte a comunicação bidirecional e desempenho em sistemas distribuídos. Além da revisão de literatura baseada em documentação técnica oficial e publicações especializadas, foram conduzidos testes práticos de carga com a ferramenta k6 em um sistema bancário implementado nas duas abordagens. Os resultados apontam redução de até 90% na latência média e 50% no volume de dados transferidos pelo gRPC frente ao REST. Contudo, o protocolo apresenta limitações relevantes: suporte restrito em navegadores web, necessidade de compartilhamento de arquivos .proto entre equipes e menor facilidade de depuração. A escolha entre os dois protocolos deve partir dos requisitos concretos do sistema.
Palavras-chave: gRPC. Microsserviços. Protocol Buffers. REST. HTTP/2. Arquitetura de Software.
1 INTRODUÇÃO
Definir como serviços se comunicam é uma das decisões arquiteturais com maior impacto prático em sistemas distribuídos. Essa escolha afeta latência, consumo de banda, facilidade de depuração e até a dinâmica de trabalho entre equipes. Por anos, o padrão REST sobre HTTP/1.1 com JSON respondeu bem a essa demanda — simples de adotar, amplamente documentado e compatível com qualquer cliente HTTP.
O problema é que essa simplicidade tem um custo que se torna visível em escala. JSON é um formato textual: legível, mas computacionalmente mais caro de serializar e desserializar que formatos binários. O HTTP/1.1 não multiplexa requisições — cada chamada precisa de sua própria conexão TCP ou enfrenta bloqueio de fila. Em sistemas com dezenas de microsserviços trocando mensagens continuamente, esses custos se acumulam (INDRASIRI; KURUPPU, 2020).
O gRPC surgiu como resposta direta a esses problemas. Desenvolvido pelo Google e aberto em 2016, o framework combina HTTP/2 — que resolve o problema de multiplexação — com Protocol Buffers, formato binário de serialização que produz mensagens menores e mais rápidas de processar. Além disso, define contratos de interface em arquivos .proto com tipagem estática, o que elimina boa
parte das incompatibilidades silenciosas comuns em APIs REST (GRPC.IO, 2026).
Este trabalho tem como objetivo central avaliar o gRPC como alternativa arquitetural ao REST em sistemas distribuídos, com foco em três dimensões: eficiência de serialização, suporte a comunicação bidirecional e desempenho sob carga. Para isso, combinamos revisão de literatura técnica com testes práticos em um sistema bancário implementado nas duas abordagens. A pergunta que orienta o estudo é objetiva: em quais condições o gRPC é tecnicamente superior ao REST, e quais são os custos reais dessa troca?
2 FUNDAMENTAÇÃO TEÓRICA
2.1 Estrutura técnica do gRPC
O gRPC organiza a comunicação entre serviços como chamadas de
funções remotas, não como troca de recursos via URL. Isso muda a forma de pensar a API: ao invés de endpoints como GET /contas/{id}, o desenvolvedor define métodos como BuscarConta(request) em um arquivo .proto, e o framework gera automaticamente o código cliente e servidor para as linguagens de destino (GRPC.IO, 2026).
Essa geração automática de código é possível porque os contratos .proto têm tipagem estática — cada campo tem tipo, nome e número de campo definidos. A serialização ocorre em Protocol Buffers, formato binário compacto desenvolvido pelo próprio Google. A mensagem resultante é menor que o equivalente em JSON e exige menos CPU para processar nos dois sentidos (INDRASIRI; KURUPPU, 2020).
Na camada de transporte, o gRPC usa exclusivamente HTTP/2. Isso traz dois benefícios concretos: multiplexação de requisições em uma única conexão TCP, eliminando o head-of-line blocking do HTTP/1.1, e compressão de cabeçalhos via algoritmo HPACK, reduzindo a sobrecarga de metadados em chamadas frequentes (MICROSOFT, 2026).
2.2 Modalidades de comunicação
Uma das diferenças mais práticas entre gRPC e REST está nas
modalidades de comunicação disponíveis. O REST opera estritamente no modelo requisição-resposta: o cliente envia uma requisição e aguarda uma resposta completa. Para comunicação em tempo real, é necessário recorrer a soluções externas como WebSockets ou Server-Sent Events.
O gRPC suporta nativamente quatro modalidades. A unária é equivalente ao modelo REST: uma requisição, uma resposta. O streaming do servidor permite que o servidor envie múltiplas mensagens em resposta a uma única requisição — útil para feeds de dados ou notificações. O streaming do cliente inverte o sentido: o
cliente envia múltiplas mensagens e recebe uma resposta ao final. O streaming bidirecional permite que ambos os lados enviem e recebam mensagens simultaneamente, sem sequência fixa (JHA, 2026).
Essa flexibilidade é relevante em sistemas que precisam de baixa latência em comunicação contínua, como pipelines de processamento em tempo real, sistemas de telemetria ou jogos multiplayer. Para APIs convencionais de consulta e atualização, a modalidade unária já entrega os ganhos de desempenho do protocolo.
2.3 Comparação com REST: trade-offs reais
A comparação entre gRPC e REST não é uma questão de qual é melhor em absoluto — é uma questão de contexto. Cada protocolo tem vantagens claras em cenários distintos.
O REST tem dois pontos fortes que o gRPC não consegue superar:
simplicidade de adoção e compatibilidade universal com navegadores. Qualquer cliente HTTP pode consumir uma API REST sem configuração adicional. O JSON é legível durante a depuração — o desenvolvedor consegue inspecionar o tráfego sem ferramentas especializadas. Isso reduz a curva de aprendizado e facilita a integração com parceiros externos.
O gRPC exige que cliente e servidor compartilhem os arquivos .proto e as bibliotecas do framework. Isso aumenta o acoplamento entre equipes e complica o setup inicial. O formato binário das mensagens impede a inspeção direta do tráfego em ferramentas como curl ou Postman sem plugins específicos. O suporte a navegadores é limitado — aplicações web precisam de uma camada intermediária, o gRPC-Web, que adiciona complexidade à arquitetura (MICROSOFT, 2026; AHMAD,2026).
Em contrapartida, o gRPC entrega ganhos mensuráveis em latência,
consumo de banda e throughput para comunicações internas entre serviços. Os contratos .proto com tipagem estática reduzem incompatibilidades entre versões e tornam a evolução da API mais controlada. Para integrações internas em sistemas de alto volume, esses benefícios geralmente superam os custos de adoção (SILVA, 2025).
3 ANÁLISE COMPARATIVA DE DESEMPENHO
3.1 Configuração do experimento
Para avaliar empiricamente as diferenças entre os protocolos,
desenvolvemos um sistema de gestão bancária em duas versões — uma com REST e outra com gRPC. As duas implementações compartilham as mesmas camadas de domínio e repositório, diferindo apenas na camada de comunicação. Os projetos estão disponíveis publicamente nos repositórios GestaoBancariaRest (VIEIRA, 2026a) e GestaoBancariaGrpc (VIEIRA, 2026b).
Os testes de carga foram executados com k6, ferramenta de teste de desempenho de código aberto. Cada cenário simulou até 50 usuários virtuais simultâneos ao longo de 50 segundos, totalizando centenas de requisições por teste. Os cenários cobriram dois casos de uso distintos: listagem simples de contas e geração de extrato bancário com volume maior de dados.
É importante registrar uma limitação do experimento: o banco de dados utilizado foi SQLite, que não foi projetado para alta concorrência. Os picos de latência máxima observados nos testes refletem contenção no banco sob carga simultânea, não limitações intrínsecas dos protocolos em si. Para um estudo de produção, PostgreSQL ou outro banco transacional seria a escolha correta.
3.2 Resultados
Os resultados estão consolidados na tabela abaixo:
O resultado mais expressivo foi a latência no cenário de listagem de
contas: 1,63 ms no gRPC contra 15,74 ms no REST, redução de 90%. No cenário de extrato bancário com 1.000 movimentos por conta, o gRPC registrou 31,32 ms frente aos 112,66 ms do REST, redução de 72%. Esses números confirmam o que a literatura técnica descreve sobre os benefícios da serialização binária e da multiplexação HTTP/2.
A diferença de volume de dados é igualmente relevante: o mesmo
conjunto de informações ocupou 96 KB em JSON e 43 KB em Protobuf por
requisição — redução de 55%. Ao longo de um teste de 50 segundos, isso se traduziu em 99 MB transferidos pelo REST contra 49 MB pelo gRPC. Em sistemas com alto volume de chamadas internas, essa diferença tem impacto direto em custo de infraestrutura e consumo de rede.
4 CONSIDERAÇÕES FINAIS
Os resultados deste trabalho mostram que o gRPC entrega ganhos reais
de desempenho frente ao REST em comunicações internas entre microsserviços. A combinação de serialização binária com Protocol Buffers e multiplexação via HTTP/2 reduz latência e consumo de banda de forma mensurável — em nossos testes, reduções de 72% a 90% na latência média e 50% no volume de dados transferidos.
Esses ganhos, porém, têm um preço. A adoção do gRPC exige que
cliente e servidor compartilhem arquivos .proto e bibliotecas específicas, o que aumenta o acoplamento entre equipes. A depuração é mais trabalhosa: sem ferramentas adequadas, o formato binário das mensagens não é legível diretamente.
O suporte a navegadores é limitado, tornando o protocolo pouco prático para APIs de front-end sem a adição do gRPC-Web. Esses custos são reais e devem ser considerados antes de qualquer migração.
A conclusão prática é direta: gRPC é a escolha tecnicamente mais
adequada para integrações internas de alto desempenho em arquiteturas de microsserviços. REST continua sendo a opção correta para APIs públicas, integrações com parceiros externos e qualquer contexto em que simplicidade de adoção e compatibilidade com navegadores sejam prioridades.
Para trabalhos futuros, recomendamos replicar os testes com PostgreSQL em vez de SQLite, para isolar com mais precisão o desempenho dos protocolos.
Também seria relevante explorar os cenários de streaming bidirecional do gRPC — a modalidade de maior diferenciação em relação ao REST, mas que este estudo não cobriu empiricamente.
REFERÊNCIAS
AHMAD, Arslan. API Design for Beginners: Understanding REST, GraphQL, and gRPC. Stackademic, 2026. Disponível em:
https://medium.com/stackademic/api-design-for-beginners-understanding-rest-graphql-and-grpc-8485b52b0c4c. Acesso em: abr. 2026.
GRPC.IO. Introduction to gRPC. 2026. Disponível em:
https://grpc.io/docs/what-is-grpc/introduction/. Acesso em: abr. 2026.
INDRASIRI, Kasun; KURUPPU, Danesh. gRPC: Up and Running. Sebastopol:
O'Reilly Media, 2020.
JHA, Shubham. REST vs gRPC: The Architecture Decision That Defines Your Microservices Performance. Medium, 2026. Disponível em:
https://medium.com/@shubhamjha642/rest-vs-grpc-the-architecture-decision-that-defines-your-microservices-performance-e5ad8376b53c. Acesso em: abr. 2026.
MICROSOFT. gRPC – .NET. Microsoft Learn, 2026. Disponível em:
https://learn.microsoft.com/pt-br/aspnet/core/grpc/. Acesso em: abr. 2026.
MICROSOFT. gRPC for WCF Developers. dotnet-architecture eBooks, 2026. Disponível em:
https://docs.microsoft.com/dotnet/architecture/grpc-for-wcf-developers/. Acesso em: abr. 2026.
SILVA, J. P. gRPC (Google Remote Procedure Call): estrutura universal de código aberto. 2025.
VIEIRA, Jean Vitor. GestaoBancariaRest. GitHub, 2026a. Disponível em: https://github.com/jeanvitorvieira/GestaoBancariaRest. Acesso em: abr. 2026.
VIEIRA, Jean Vitor. GestaoBancariaGrpc. GitHub, 2026b. Disponível em: https://github.com/jeanvitorvieira/GestaoBancariaGrpc. Acesso em: abr. 2026.
GLOSSÁRIO
API (Application Programming Interface): conjunto de definições e protocolos que viabiliza a integração entre sistemas de software, expondo funcionalidades de forma padronizada.
gRPC (Google Remote Procedure Call): framework de código aberto mantido pelo Google para chamadas de procedimento remoto entre sistemas distribuídos, baseado em HTTP/2 e em Protocol Buffers.
HPACK: algoritmo de compressão de cabeçalhos HTTP especificado para o HTTP/2, responsável por reduzir a sobrecarga de metadados nas requisições.
HTTP/2: segunda versão do protocolo HTTP, que introduz multiplexação, compressão de cabeçalhos e server push sobre uma única conexão TCP.
JSON (JavaScript Object Notation): formato textual de intercâmbio de dados, legível por humanos, amplamente adotado em APIs REST.
Microsserviço: estilo arquitetural em que uma aplicação é estruturada como um conjunto de serviços pequenos, autônomos e implantáveis de forma independente.
Multiplexação: capacidade de transmitir múltiplas requisições e respostas simultaneamente sobre uma mesma conexão de rede.
Protocol Buffers: mecanismo de serialização binária desenvolvido pelo Google, orientado à definição estrita de contratos por meio de arquivos .proto.
REST (Representational State Transfer): estilo arquitetural para sistemas distribuídos baseado em HTTP, que utiliza métodos padronizados e representações, tipicamente em JSON.
RPC (Remote Procedure Call): paradigma de comunicação em que um programa invoca procedimentos executados em outro espaço de endereçamento, de forma análoga a uma chamada local.
Serialização: processo de conversão de estruturas de dados ou objetos em um formato transmissível pela rede ou armazenável em disco.
Streaming: modalidade de comunicação em que os dados são transmitidos continuamente como fluxo, em vez de em uma única resposta completa.
Top comments (0)