System Design/04 - Cloud Design Patterns/Messaging2 min
Claim Check
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Guardar o payload grande num armazenamento externo e enviar pela mensagem apenas uma referência — como um ticket de bagagem.
sem claim check: [ mensagem de 50 MB ] → fila
com claim check: arquivo → armazenamento
[ { "ref": "s3://bucket/abc" } ] → fila (200 bytes)
O consumidor recebe a referência e busca o conteúdo quando precisa.
Por que é frequentemente obrigatório
A maioria dos brokers tem limite rígido de tamanho: 256 KB no SQS, 1 MB por padrão no Kafka, 256 KB no Service Bus. Acima disso, não é uma otimização — é a única forma.
Trade-offs
O ganho vai além de contornar o limite: mensagens pequenas trafegam mais rápido, o broker guarda muito mais delas em memória, e o custo de armazenamento migra para um lugar ordens de grandeza mais barato.
Os custos:
Mais um componente no caminho. O consumidor precisa de acesso ao armazenamento, e uma falha lá quebra o processamento mesmo com a fila saudável.
Ciclo de vida desacoplado. A mensagem e o dado passam a viver em lugares diferentes, com políticas de retenção diferentes. Se o objeto expira antes de a mensagem ser consumida, o consumidor recebe uma referência morta — e se a mensagem se perde, o objeto fica órfão, ocupando espaço para sempre.
A correção usual é dar ao objeto um TTL maior que a retenção da fila, e rodar limpeza periódica de órfãos.
Consistência entre os dois passos. Gravar o objeto e publicar a mensagem não é atômico. A ordem correta é gravar primeiro e publicar depois: assim, o pior caso é um órfão (detectável e limpável), não uma referência quebrada.
E a segurança segue junto: a referência precisa ser inútil para quem não tem permissão. Combinar com Valet Key resolve, dando ao consumidor acesso temporário e escopado.
Exemplo prático
Processamento de imagens de 20 MB.
1. upload direto para o armazenamento (via URL assinada)
2. publica { "ref": "s3://uploads/abc123", "tipo": "imagem/jpeg" }
3. worker consome, baixa o objeto, processa
4. worker grava o resultado e apaga o original
A fila trafega centenas de bytes por mensagem em vez de 20 MB. Isso muda o que o broker consegue sustentar: com 10 mil mensagens pendentes, a diferença é entre 2 MB e 200 GB em trânsito.
O passo 4 é o que evita o acúmulo de órfãos — e, mesmo assim, uma limpeza periódica de objetos sem mensagem correspondente continua sendo necessária, porque nem todo worker chega ao passo 4.
Relacionado
Parte de Messaging · roadmap.sh/system-design