MessagePack vs JSON: Tamanho, Velocidade e Overhead comparados

MessagePack é um formato de serialização binário criado por Sadayuki Furuhashi em 2008 e publicado como especificação aberta. Ele codifica os mesmos tipos de dados que o JSON - null, boolean, integer, float, string, array, map - mas usa representações binárias compactas em vez de texto legível por humanos. Um `true` booleano que ocupa 4 bytes como texto JSON ocupa exatamente 1 byte em MessagePack. Um inteiro pequeno como 42 ocupa 3 bytes em JSON e 1 byte em MessagePack.

O formato é sem schema: assim como o JSON, não exige um schema predefinido para codificar ou decodificar dados. Isso o torna um substituto direto do JSON na maioria dos contextos de API - você troca o serializador sem mudar o modelo de dados. MessagePack tem amplo suporte, com bibliotecas oficiais e da comunidade em Python, JavaScript, Go, Ruby, Java, C++, Rust e mais de 50 outras linguagens.

Como funciona a codificação MessagePack

• Byte de tag de tipo - cada valor começa com uma tag de 1 byte que codifica o tipo e, para valores pequenos, o próprio valor (fixint, fixstr, fixarray, fixmap).
• Inteiros - inteiros pequenos (0-127) ocupam 1 byte no total. Inteiros maiores usam 2, 4 ou 8 bytes conforme a magnitude, sempre menores que sua representação decimal em texto.
• Strings - codificadas como uma sequência de bytes UTF-8 prefixada pelo comprimento. Strings curtas (≤31 caracteres) usam cabeçalho de 1 byte; strings longas usam cabeçalho de 2 ou 4 bytes.
• Booleanos e null - cada um ocupa exatamente 1 byte. Em JSON, `true` tem 4 bytes, `false` tem 5 bytes e `null` tem 4 bytes.
• Arrays e maps - prefixados pelo comprimento; arrays pequenos (≤15 elementos) usam 1 byte de overhead, contra os colchetes `[` `]` e as vírgulas do JSON.

A redução de tamanho ao migrar para MessagePack depende inteiramente da composição dos dados do seu payload. Payloads com muitos campos numéricos, booleanos e valores null obtêm os maiores ganhos. Payloads com muitas strings - textos longos, UUIDs, datas ISO - ganham menos, porque o conteúdo da string é armazenado como bytes UTF-8 crus nos dois formatos.

A economia vem das informações de tipo e do overhead estrutural, não da compressão dos próprios valores. Uma string de 200 caracteres custa praticamente o mesmo nos dois formatos.

Comparação de tamanho por tipo de dado

Benchmarks de payloads do mundo real

Uma resposta típica de API REST com tipos de dados mistos - IDs, nomes, timestamps, flags de status e contadores - apresenta redução de 20-35%. Um payload de dados puramente numéricos (leituras de sensores, eventos de analytics) pode chegar a 40-50% de redução. Um payload com muitas strings longas (corpos de artigos, mensagens de log) pode ter apenas 5-15% de redução. A ferramenta Comparação de Tamanho JSON vs MessagePack do Aback Tools mede a economia exata em bytes para qualquer payload JSON específico - cole seu payload de produção e leia a porcentagem real em menos de um segundo.

A serialização e desserialização com MessagePack é tipicamente 2-4x mais rápida que o processamento de JSON em texto padrão nos benchmarks. A vantagem de velocidade vem de pular a tokenização UTF-8: parsers JSON precisam escanear cada byte procurando caracteres estruturais (chaves, aspas, vírgulas, dois-pontos), enquanto parsers MessagePack leem uma tag de tipo e saltam direto para o limite do próximo valor. Sem varredura de aspas, sem tratamento de escape, sem conversão de string numérica para inteiro.

Contexto de performance por linguagem

A diferença de velocidade varia bastante conforme o runtime. Em Python, o `msgpack` é 3-5x mais rápido que o módulo padrão `json` em payloads típicos. Porém, o `orjson` (biblioteca JSON para Python com núcleo em Rust) é quase tão rápido quanto o `msgpack` em muitas cargas - a diferença cai para 1,2-1,5x. Em Node.js, o `@msgpack/msgpack` supera o `JSON.parse` nativo em cerca de 2x. Em Go, a diferença é ainda menor, porque o `encoding/json` padrão do Go já é bem rápido.

Onde a velocidade importa mais

O ganho de velocidade de serialização faz mais sentido na comunicação interna entre microsserviços de alto throughput, onde os serviços trocam milhares de mensagens por segundo e a serialização é um custo de CPU mensurável. Para uma API web padrão que atende algumas centenas de requisições por segundo, a diferença de tempo de serialização entre JSON e MessagePack é desprezível comparada ao tempo de consulta ao banco de dados ou à latência de rede. Faça profiling do seu gargalo real antes de otimizar a serialização.

MessagePack e JSON compartilham o mesmo conjunto de tipos essenciais - null, boolean, number, string, array e object/map - mas o MessagePack é mais rico nos níveis numérico e binário. Essas diferenças importam quando você migra uma API JSON existente ou projeta um novo protocolo, porque alguns tipos MessagePack não têm equivalente direto em JSON.

Tipos que o MessagePack adiciona além do JSON

• Inteiro de 64 bits sem sinal - o JSON não tem tipo inteiro (números são doubles IEEE 754, que perdem precisão acima de 2^53). O MessagePack codifica valores uint64 com precisão.
• Array de bytes binário - o MessagePack tem um tipo bin nativo para sequências de bytes crus. O JSON não tem equivalente - dados binários precisam ser codificados em base64 como string, adicionando ~33% de overhead.
• Tipos de extensão - mecanismo reservado para tipos específicos da aplicação, como timestamps (ext type 1), decimais e dados marcados personalizados. Permite enriquecimento semântico sem schema.
• Float32 - o MessagePack pode codificar floats de 32 bits (4 bytes). O JSON sempre usa representação textual em precisão dupla de 64 bits, que é maior e perde a informação de tipo f32.

O problema de ida e volta de tipos

Uma pegadinha crítica ao migrar de JSON para MessagePack: o JSON tem apenas um tipo numérico (double IEEE 754), enquanto o MessagePack distingue int8, int16, int32, int64, uint8-uint64, float32 e float64. Se sua aplicação serializa um número JSON e o desserializa como MessagePack, o tipo pode mudar. Um valor como 42 serializado em JavaScript (como double) pode ser desserializado em uma linguagem fortemente tipada como uint8. Sempre verifique o comportamento de ida e volta entre sua biblioteca de serialização e o serviço consumidor.

Timestamps do MessagePack

O tipo de extensão 1 do MessagePack é um formato de timestamp padronizado que codifica o tempo Unix como valor binário de 4, 8 ou 12 bytes com precisão de nanossegundos. É menor e mais preciso que uma string ISO 8601 como `"2026-06-11T14:30:00Z"` (20 bytes como JSON) e evita ambiguidade de fuso horário. A maioria das bibliotecas MessagePack codifica e decodifica esse tipo de extensão automaticamente, tornando o tratamento de timestamps transparente para a camada de aplicação.

A escolha entre MessagePack e JSON não é sobre qual formato é "melhor" - é sobre quais restrições importam em um determinado contexto. O JSON vence em universalidade, ferramental e depuração. O MessagePack vence em tamanho de payload e velocidade de parsing. A maioria das APIs deve começar com JSON e migrar para MessagePack somente depois que o profiling confirmar que a serialização ou o tamanho do payload é um gargalo real.

Use MessagePack quando

• Comunicação interna entre microsserviços - serviços que você controla nas duas pontas, onde legibilidade humana não é necessária e o throughput é uma preocupação mensurável.
• Brokers de mensagens de alta frequência - tópicos Kafka, NATS e RabbitMQ transportando milhares de eventos por segundo, onde o tamanho do payload impacta diretamente o throughput e os custos de armazenamento.
• APIs móveis com banda limitada - reduzir o tamanho do payload em 30% em uma API móvel de alto tráfego reduz de forma relevante o consumo de dados e a latência em conexões celulares.
• Protocolos de jogos em tempo real ou IoT - onde frames binários, latência abaixo de um milissegundo e eficiência de banda são requisitos de projeto desde o início.
• Transporte de dados binários - payloads com bytes crus (imagens, trechos de áudio, material criptográfico) evitam os 33% de overhead do base64 na codificação JSON.

Fique com JSON quando

• APIs públicas - consumidores externos esperam JSON; adicionar MessagePack exige adoção de bibliotecas no lado do cliente e middleware de negociação de conteúdo.
• Ferramental para desenvolvedores - DevTools do navegador, curl, Postman e exploradores de API funcionam nativamente com JSON; depurar MessagePack exige etapas extras de decodificação.
• Endpoints de baixo tráfego - o custo de engenharia de adicionar suporte a MessagePack supera em muito o benefício quando o volume de payload é pequeno.
• Compressão gzip já em uso - o gzip HTTP ou Brotli comprime agressivamente os nomes de chaves repetitivos do JSON, muitas vezes alcançando redução semelhante ao MessagePack puro.

MessagePack tem suporte maduro de bibliotecas em todas as principais linguagens, mas não é suportado nativamente em navegadores nem em frameworks HTTP padrão como o JSON é. Adicionar MessagePack a uma stack existente significa adicionar uma dependência, atualizar o tratamento de content-type e atualizar qualquer ferramental de depuração ou log que consuma corpos de requisição/resposta crus.

Suporte de bibliotecas por linguagem

• Python - `msgpack` (PyPI). Extensão C rápida com fallback em Python puro. Substituto direto do `json` na maioria dos casos.
• JavaScript / Node.js - `@msgpack/msgpack` (npm). Nativo em TypeScript, com suporte a streaming. Também `msgpackr` para maior performance.
• Go - `github.com/vmihailenco/msgpack` ou `github.com/ugorji/go/codec`. Ambos implementam a especificação completa com suporte a tipos de extensão.
• Java / JVM - `msgpack-java` (oficial). Integra-se ao Jackson via `jackson-dataformat-msgpack` como substituto direto do JSON.
• Rust - `rmp` e `rmp-serde`. A serialização baseada em Serde faz de adicionar MessagePack ao lado do JSON existente uma mudança de uma linha.

Validando seu payload antes de codificar

Antes de migrar uma API de produção para MessagePack, valide a estrutura JSON que você está codificando. Um payload JSON com erros estruturais - vírgulas finais, chaves sem aspas, nulls inesperados - produzirá silenciosamente uma saída MessagePack malformada que causa erros de decodificação crípticos no lado do consumidor. Passe seu payload pelo JSON Formatter Viewer para verificar a estrutura e pelo Validador de JSON Schema para confirmar que ele está em conformidade com o formato esperado antes de codificar.

MessagePack não é um upgrade gratuito em relação ao JSON. O formato binário introduz custos reais em depuração, compatibilidade de ferramental e onboarding de desenvolvedores. Não são preocupações hipotéticas - são o principal motivo pelo qual a maioria das equipes que avaliam MessagePack acaba mantendo JSON para tudo, exceto os canais internos específicos de alto volume em que o trade-off claramente compensa.

A depuração é o maior custo prático

Com JSON, você pode ler um corpo de requisição cru no terminal, no DevTools do navegador ou em qualquer log de texto. Com MessagePack, você vê saída binária como `\x81\xa4name\xa5Alice`. Toda sessão de depuração exige uma etapa de decodificação. Equipes que usam MessagePack em produção costumam adicionar um utilitário dedicado de decodificação ao seu ferramental interno e registrar os payloads decodificados na stack de observabilidade ao lado dos frames binários. O atrito no desenvolvimento é real - não o subestime.

Evolução de schema e versionamento

MessagePack é sem schema, como o JSON, então adicionar ou remover campos não quebra o formato. Porém, a ausência de schema significa que não há mecanismo de compatibilidade retroativa embutido além da verificação de campos em nível de aplicação. Para APIs em evolução, os tipos de extensão do MessagePack podem carregar metadados de versão de schema, mas isso exige design explícito. Para protocolos estritamente tipados e em evolução, a evolução de schema baseada em números de campo do Protobuf é mais robusta - veja a comparação JSON Schema vs Protobuf para a análise completa do trade-off.

O equalizador gzip

A compressão gzip HTTP muitas vezes fecha drasticamente a diferença entre JSON e MessagePack. APIs JSON com chaves repetitivas ao longo de elementos de array se comprimem extremamente bem, porque o gzip explora essa repetição. Uma resposta típica de API 40% menor como MessagePack puro pode ser apenas 5-10% menor depois que os dois formatos passam por gzip. Sempre faça benchmark de MessagePack comprimido contra JSON comprimido antes de se comprometer com uma migração.