Limites de payload e anexos internos sem transformar fila em caminhão de JSON

O problema

Quando o sistema é pequeno, mandar tudo parece conveniente.

Então começam coisas assim:

• evento com snapshot inteiro
• job com documento grande embutido
• fila carregando JSON gigante com campos que ninguém usa

Parece prático para o consumidor.

Mas a conta chega em:

• serialização
• rede
• memória
• retry
• custo de observabilidade

E, pior, em acoplamento.

Modelo mental

Fila, evento e job normalmente deveriam carregar:

• identidade do alvo
• contexto mínimo
• instrução ou fato

Não deveriam, por padrão, virar:

• repositório de anexos
• dump completo de documento
• transporte universal para qualquer dado pesado

Quando isso acontece, a infraestrutura de mensagem começa a fazer o papel errado.

Exemplo simples

Imagine um fluxo de processamento de nota fiscal em PDF.

Uma versão pior manda no job:

• o PDF inteiro em base64
• metadata grande
• cópia de campos que já estão persistidos

Uma versão melhor costuma mandar:

• invoice_id
• referência do arquivo
• tenant
• correlation id
• instrução do processamento

Assim o job puxa o anexo de onde ele realmente deveria morar.

O erro comum

O erro comum é pensar:

“manda tudo e o consumidor decide o que usa”

Isso resolve a conveniência local e piora o sistema inteiro.

Outro erro comum é justificar payload enorme com “menos lookup”.

Às vezes é verdade.

Mas muitas vezes você só trocou um lookup barato por:

• contrato inflado
• retry caro
• debug ruim
• infra sobrecarregada

O que normalmente ajuda

Ajuda definir algumas fronteiras simples:

• o que viaja inline
• o que vai por referência
• o que já deveria estar persistido antes
• qual é o tamanho aceitável do contrato

Também ajuda tratar payload como parte da operabilidade:

• quanto custa reprocessar?
• quanto custa duplicar?
• quanto custa observar?

Isso força o time a sair do “funciona no happy path” e pensar no ciclo inteiro.

Como um senior pensa

Quem já viu fila virar caminhão de JSON costuma perguntar:

• isso realmente precisa viajar junto?
• se eu reexecutar esse job mil vezes, o custo continua razoável?
• estou usando fila como transporte ou como armazenamento improvisado?
• esse contrato vai continuar entendível depois de crescer mais 30%?

Essa conversa evita crescimento burro de payload.

Ângulo de entrevista

Esse tema aparece em backend, mensageria, processamento de arquivos, eventos e system design.

O entrevistador quer ver se você entende:

• que payload tem custo operacional real
• que mensagem boa carrega intenção e contexto suficiente, não excesso
• que anexos e blobs costumam pedir referência, não embedding cego

Resposta forte costuma soar assim:

“Eu evitaria usar fila como caminhão de JSON. Preferiria mandar identidade, contexto mínimo e referência para anexos quando necessário. Payload inflado encarece retry, observabilidade e evolução do contrato.”

Takeaway direto

Payload bom carrega o suficiente para agir.

Quando ele carrega o mundo inteiro, o sistema começa a pagar por isso em todos os lados.