Descomplicando RPC e gRPC

O problema: acoplamento implícito e sobrecarga de protocolos

Desenvolvedores frequentemente se deparam com duas frustrações ao integrar serviços:

1. Complexidade de transporte – montar requisições HTTP, lidar com cabeçalhos, retries e time‑outs consome tempo que deveria ser dedicado à lógica de negócio.
2. Acoplamento de contrato – mudar um parâmetro ou o tipo de retorno de um endpoint costuma exigir alterações em múltiplos clientes, gerando quebras silenciosas em produção.

Essas dores são particularmente agudas em sistemas que precisam de baixa latência (por exemplo, cálculo de impostos em tempo real ou roteamento de mensagens) e que operam em escala horizontal.

A solução tradicional: RPC clássico

A chamada de procedimento remoto (RPC) surgiu como um abstração que permite ao cliente invocar uma função que, na verdade, roda em outro processo ou máquina. O fluxo típico é:

1. Client Stub – código gerado que expõe a mesma assinatura da função remota.
2. Serialização – os argumentos são convertidos para um formato de bytes (geralmente JSON, XML ou um binário proprietário).
3. Transporte – a mensagem viaja sobre TCP/UDP ou até mesmo sobre HTTP.
4. Server Stub – recebe a mensagem, desserializa e delega à implementação real.
5. Resposta – o caminho inverso entrega o resultado ao cliente.

Esse modelo esconde a rede do desenvolvedor, mas traz alguns trade‑offs críticos:

• Formato de mensagem fixo – sem um esquema formal, mudanças de contrato são frágeis.
• Latência de serialização – JSON ou XML são legíveis, mas introduzem overhead significativo em serviços de alta frequência.
• Escalabilidade limitada – a maioria das bibliotecas RPC não oferece balanceamento interno; o cliente precisa conhecer o endereço do servidor ou usar um serviço de descoberta externo.

gRPC: a evolução orientada a performance

O gRPC, mantido pela Cloud Native Computing Foundation, adota o mesmo conceito de stub, mas muda três pilares fundamentais:

1. Protocol Buffers (proto) – um IDL (Interface Definition Language) que gera código para cliente e servidor em mais de 15 linguagens. O esquema é versionado, permitindo adição de campos opcionais sem quebrar versões antigas.
2. HTTP/2 como transporte – multiplexação de streams sobre uma única conexão TCP reduz a sobrecarga de handshakes e permite push de mensagens do servidor.
3. Modelo de chamadas – além do tradicional request/response, gRPC suporta streaming bidirecional, o que simplifica casos como chat em tempo real ou ingestão de métricas.

Implicações de escalabilidade

Aspecto	RPC clássico	gRPC
Conexões	Uma conexão por chamada (geralmente HTTP/1.1).	Reuso de conexão HTTP/2; milhares de chamadas simultâneas por socket.
Throughput	Limitado por cabeçalhos verbosos e latência de serialização.	Compressão nativa de protobuf; latência tipicamente 2‑3× menor.
Balanceamento	Necessita de cliente‑side load balancer ou DNS round‑robin.	Integração com service mesh (e.g., Istio) e client‑side balancers que distribuem streams dinamicamente.

Em ambientes com milhares de micro‑serviços, essa diferença pode significar a diferença entre um cluster que consome 30 % da capacidade da rede e outro que atinge 80 %.

Consistência e tolerância a falhas

RPC e gRPC são transportes; a consistência dos dados depende da camada de aplicação.

• Modelo de consistência forte – se a chamada bloqueia até que a operação seja confirmada em um quorum, a latência aumenta, mas o cliente tem garantias de leitura‑escrita.
• Modelo eventual – usando streaming ou fire‑and‑forget, o cliente pode prosseguir antes da confirmação, aceitando que o estado se propague assincronamente.

gRPC facilita a implementação de padrões como retry e circuit breaker através de interceptors, enquanto bibliotecas RPC mais antigas exigem código boilerplate.

Padrões de API: RPC vs REST vs GraphQL

Critério	REST (HTTP/1.1)	RPC (JSON)	gRPC (proto)
Verbos	Mapeados ao método HTTP (GET, POST, PUT...).	Verbos explícitos na URI (ex.: /conversations.archive).	Métodos definidos no .proto.
Versionamento	URLs versionadas (/v1/...).	Geralmente via parâmetros ou cabeçalhos.	Compatibilidade retroativa via campos opcionais.
Caching	Suporte nativo a caches HTTP.	Pouco usado; depende de implementação customizada.	Não há cache HTTP, mas pode-se aplicar client‑side memoization.
Tooling	Swagger/OpenAPI.	Documentação ad‑hoc.	protoc gera stubs, documentação via protoc-gen-doc.

Para serviços que exigem low‑latency e contrato rígido, gRPC costuma ser a escolha natural. Quando a interoperabilidade com navegadores ou a necessidade de caching são críticas, REST ainda tem vantagem.

Quando escolher cada abordagem

Cenário	Recomendação
Integração com browsers	REST ou GraphQL (HTTP/1.1).
Comunicação entre micro‑serviços de alta frequência	gRPC com HTTP/2 + service mesh.
Sistemas legados que já expõem RPC JSON	Manter RPC, mas migrar gradualmente para protobuf.
Operações batch ou long‑running	gRPC streaming ou REST com polling.

Estratégia de migração prática

1. Inventário de contratos – extraia todos os esquemas JSON usados pelos clientes.
2. Defina proto files – mapeie cada endpoint para um método protobuf, mantendo campos opcionais para compatibilidade.
3. Gerar stubs – use protoc --go_out=plugins=grpc:. (ou a linguagem de sua escolha) para produzir código cliente/servidor.
4. Implementar gateway – um pequeno serviço que aceita chamadas REST/JSON e as encaminha para gRPC, permitindo que clientes antigos continuem funcionando.
5. Testes de carga – compare latência e throughput antes e depois; ajuste tamanho de mensagens e compressão.
6. Descomissionamento – retire o endpoint legado somente depois de validar que todos os consumidores migraram.

Conclusão

RPC continua sendo um conceito valioso porque abstrai a rede, mas a escolha da implementação tem impacto direto na escalabilidade, consistência e complexidade operacional. gRPC oferece um caminho mais eficiente para sistemas distribuídos modernos, ao mesmo tempo em que impõe disciplina de contrato via Protocol Buffers. A decisão final deve considerar requisitos de latência, ambiente de consumo (browsers vs servidores) e a maturidade da equipe em lidar com HTTP/2 e service mesh.

---

Referências úteis

• gRPC Official Site
• Protocol Buffers Documentation
• Istio Service Mesh