Código binário na prática: o que a escolha entre JSON e formatos binários custa na sua infraestrutura

Em 2023, o time de engenharia do LinkedIn trocou JSON por Protobuf em parte da stack do Rest.li. O resultado: até 60% de redução na latência P99 sob carga pesada, segundo o blog de engenharia da própria empresa (acesso em out/2026). Esse número é sólido o bastante para justificar a migração de um framework usado por dezenas de milhares de endpoints em produção.

Não foi um exercício acadêmico sobre zeros e uns. Foi uma decisão de arquitetura que, multiplicada pelo volume de requisições da plataforma, se traduziu em menos CPU gasta por chamada e menos banda trafegada por segundo.

Toda vez que seu sistema serializa um objeto para enviar pela rede, ele toma essa mesma decisão em miniatura. JSON virou o padrão por comodidade: é texto, é legível, qualquer ferramenta abre. Texto, porém, tem custo de processamento que formatos binários não têm. Esse custo aparece em três lugares que afetam diretamente sua conta de infraestrutura: CPU de parse, tamanho de payload e latência de rede.

Este artigo trata binário como ele é hoje: uma variável de custo e performance em produção, não uma curiosidade de fundamentos de computação.

Por que texto custa mais para a máquina processar?

JSON representa cada número como uma sequência de caracteres ASCII. O inteiro 1000000 vira sete bytes de texto. O parser precisa ler caractere por caractere, converter para um tipo numérico e validar sintaxe (chaves, aspas, vírgulas) no caminho. Um formato binário como Protobuf codifica o mesmo valor em um campo de tamanho fixo ou varint, sem etapa de conversão textual.

A diferença fica visível em benchmark direto. Um comparativo publicado no ProAndroidDev mediu payloads de Protobuf cerca de três vezes menores que o equivalente em JSON, com serialização mais de dez vezes mais rápida em payloads pequenos. Outro teste, rodado com bibliotecas Ruby populares, registrou o parser binário entre 4 e 8 vezes mais compacto em bytes e sensivelmente mais rápido na codificação, variando conforme a complexidade do payload.

O ganho não é uniforme. Para dados numéricos, como IDs, timestamps e métricas, Protobuf costuma produzir payloads de 4 a 5 vezes menores que JSON, por causa da codificação varint para inteiros. Já para strings longas a vantagem de tamanho encolhe, porque o texto em si já é compacto por natureza.

Onde isso aparece na conta de infraestrutura

CPU e banda são recursos cobrados em qualquer VPS ou cloud. Payload 3x menor em uma API que recebe milhões de chamadas por dia significa 3x menos dados trafegando pela rede todo santo mês. Parse mais rápido significa menos ciclos de CPU por requisição, o que em sistemas sob carga pesada se traduz em suportar mais tráfego com o mesmo hardware, ou em precisar de menos instâncias para sustentar o mesmo volume.

Isso pesa mais em alguns pontos da arquitetura do que em outros:

• Comunicação interna entre microsserviços: alto volume, baixa necessidade de legibilidade humana. É o cenário clássico onde gRPC com Protobuf substitui REST com JSON.
• Filas de mensagens: sistemas como Kafka carregam serialização binária internamente justamente para reduzir overhead em pipelines de alto throughput.
• Replicação e sincronização de dados: bancos de dados usam formatos binários próprios para replicar estado entre nós sem pagar o preço de parsing textual a cada operação.
• APIs com alta frequência de chamada: aplicativos móveis que sincronizam dados constantemente sentem o payload menor tanto em performance quanto no consumo de dados do usuário.

O que você perde ao trocar JSON por um formato binário?

Nenhuma decisão de engenharia vem sem contrapartida, e o teste de adequação aqui é direto: se a troca custa mais em complexidade do que economiza em performance, não vale a pena.

Legibilidade humana. JSON abre em qualquer editor de texto e qualquer pessoa entende o que está vendo. Um payload Protobuf é uma sequência de bytes que exige o schema .proto correspondente para ser interpretado. Debugar um payload binário em produção, sem a ferramenta certa, é bem mais difícil do que abrir um JSON e ler direto.

Fricção de desenvolvimento. Protobuf exige definir um schema, compilar esse schema para código de cada linguagem envolvida, e manter esse processo de build sincronizado entre times. JSON não pede nada disso: é serializar o objeto e seguir em frente.

Compatibilidade com cliente web. JavaScript tem JSON.parse() e JSON.stringify() nativos no navegador. Qualquer formato binário no front-end exige uma camada extra de decodificação que simplesmente não é necessária com JSON.

A razão real para adotar Protobuf raramente é só o ganho bruto de velocidade. É a definição de schema compartilhado entre linguagens diferentes, que elimina ambiguidade sobre o formato dos dados entre times que não compartilham a mesma stack.

Quando faz sentido manter JSON

• APIs públicas consumidas por terceiros que você não controla. Forçar um formato binário aumenta a barreira de integração sem necessidade.
• Configuração e arquivos que humanos precisam editar manualmente. Ninguém quer abrir um binário para mudar uma flag.
• Times pequenos ou MVPs onde o volume de tráfego ainda não justifica a complexidade adicional de schema e build.
• Qualquer sistema onde debugabilidade em produção pesa mais que economia de CPU.

Checklist de decisão

Antes de trocar o formato de serialização de um sistema em produção, três perguntas concretas substituem a intuição:

1. Qual o volume real de requisições? Payload 3x menor em um sistema com baixo tráfego não move a agulha. Em alto volume, multiplicado pelo número de chamadas, o ganho acumulado em banda e CPU fica visível na fatura.
2. Quem consome essa API, humano ou máquina? Comunicação máquina-a-máquina (microsserviços, filas, replicação) tolera bem formato binário. Interface consumida por humanos ou por terceiros externos pede a legibilidade do texto.
3. Sua equipe tem capacidade de manter o processo de schema? Protobuf exige definição de .proto, geração de código e sincronização entre times. Se essa estrutura não existe hoje, o custo de implementação pode superar o ganho de performance no curto prazo.

A resposta raramente é binário em tudo ou JSON em tudo. Sistemas de produção maduros costumam combinar os dois: JSON na borda, onde humanos e integrações externas interagem, formato binário onde volume e performance decidem a conta de infraestrutura no fim do mês. Essa divisão só funciona quando há uma base de schema bem versionada sustentando a comunicação interna, para que a troca de formato não vire fonte de bugs de compatibilidade entre times.

Essa mesma lógica de origem, decisão de arquitetura e consequência concreta aparece em outras camadas da lógica de programação por trás de um sistema em produção: cada estrutura de dados escolhida carrega um custo computacional que só aparece sob carga real.

Performance de infraestrutura entra na equação

Reduzir o custo de CPU e banda por requisição é só metade da equação. A outra metade é onde esse sistema roda. Um Servidor VPS com recursos dedicados entrega previsibilidade para microsserviços que processam payloads binários em alto volume, sem o ruído de performance de um ambiente compartilhado.

Para arquiteturas que precisam escalar com o crescimento do tráfego, sem reconfigurar servidor a cada pico de demanda, o Locaweb Cloud oferece recursos isolados que acompanham a curva de uso, com cobrança em reais e data center no Brasil, o que reduz latência de rede para aplicações que atendem majoritariamente usuários brasileiros. É o mesmo raciocínio de reduzir overhead na camada de dados aplicado à camada de infraestrutura: menos desperdício, mais previsibilidade sob carga.

Segurança e governança de dados também entram nessa conta de arquitetura. Se o seu sistema lida com dados sensíveis, vale entender como soberania de dados se conecta à decisão de onde e como seus dados trafegam e são armazenados.

FAQ – Perguntas frequentes sobre código binário e serialização