System Design/02 - Componentes/Communication2 min
gRPC
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Framework RPC da Google sobre HTTP/2 com serialização Protocol Buffers. O contrato é declarado num arquivo .proto que gera código de cliente e servidor.
service PedidoService {
rpc Buscar(BuscarRequest) returns (Pedido);
rpc Acompanhar(PedidoId) returns (stream StatusUpdate);
}
message Pedido { int64 id = 1; double total = 2; }Os quatro modos de chamada
| Modo | Formato |
|---|---|
| Unary | 1 requisição → 1 resposta |
| Server streaming | 1 → N (acompanhar status, feed) |
| Client streaming | N → 1 (upload em partes, telemetria) |
| Bidirectional | N ↔ N (chat, sincronização) |
Por que é rápido
- Protobuf é binário — tipicamente 3 a 10x menor que JSON equivalente
- HTTP/2 multiplexa; várias chamadas numa conexão
- Serialização e desserialização muito mais baratas que parse de JSON
- Código gerado, sem reflexão em tempo de execução
Trade-offs
| Ganha | Perde |
|---|---|
| Contrato forte, verificado em compilação | Não funciona direto no navegador |
| Payload pequeno, baixa latência | Payload ilegível sem ferramenta |
| Streaming nativo nos dois sentidos | Cache HTTP não se aplica |
| Código gerado em várias linguagens | Requer geração no build |
O navegador não fala gRPC nativamente porque não expõe controle suficiente sobre HTTP/2 — daí gRPC-Web, que exige um proxy de tradução (Envoy) e perde o client streaming.
A ilegibilidade do payload é um custo operacional real: não dá para depurar com curl, e ferramentas de rede mostram bytes. grpcurl e reflexão do servidor mitigam.
O contrato forte é a maior vantagem e a maior disciplina: mudar um campo exige respeitar as regras de compatibilidade do Protobuf (nunca reutilizar número de campo, nunca mudar tipo, adicionar em vez de renomear). Quebrar isso corrompe dados silenciosamente, sem erro de compilação.
Por isso a divisão que se consolidou: gRPC para dentro, REST/GraphQL para fora.
Exemplo prático
Um serviço interno chamado 50 mil vezes por segundo entre microserviços.
REST + JSON: ~800 bytes/resposta, parse custoso, 1 requisição por conexão em HTTP/1.1
gRPC: ~120 bytes/resposta, binário, multiplexado em HTTP/2
A diferença de banda sozinha (~34 GB/hora contra ~5 GB/hora) já muda o custo de rede. Somada ao menor uso de CPU em serialização, é o tipo de ganho que justifica a troca em caminho quente.
A mesma escolha seria ruim numa API pública: parceiros precisariam gerar stubs, não conseguiriam testar com curl, e nenhum cache de borda funcionaria.
Relacionado
Parte de Communication · roadmap.sh/system-design