Multipart, Checksums e Escritas Condicionais no S3

Multipart por dentro

Multipart divide um upload em partes identificadas por número. O cliente inicia o upload, envia as partes e conclui com a lista que compõe o objeto. Uma parte que falha pode ser reenviada sem retransmitir todo o conteúdo.

O objeto completo aparece depois da conclusão bem-sucedida. Partes de um upload que nunca foi concluído podem continuar ocupando armazenamento e gerando cobrança até serem abortadas ou removidas por uma regra apropriada. Referência: ciclo multipart.

Curiosidade: ETag não é uma promessa de MD5

ETag identifica uma versão de representação conforme o comportamento da operação. Ele não deve ser tratado universalmente como o MD5 do conteúdo: multipart e formas de criptografia mudam essa relação. Para verificar integridade, use os mecanismos de checksum suportados e entenda se o checksum cobre partes ou o objeto completo. Referência: integridade de objetos.

Considere dois downloads iguais montados por estratégias de upload diferentes. Concluir que são arquivos diferentes apenas porque os ETags diferem pode estar errado. O significado do identificador depende da operação que o produziu.

Evitar sobrescrita acidental

Uma leitura seguida de escrita incondicional deixa uma janela:

A le versao X.
B le versao X.
A escreve Y.
B escreve Z usando a decisao tomada sobre X: Y desaparece do estado atual.

Escritas condicionais fecham a janela quando a operação e o tipo de bucket suportam a condição desejada. If-None-Match: * solicita criar somente se a chave não existir; If-Match condiciona a escrita ao ETag esperado.

Se a condição falhar, a aplicação deve reavaliar o estado. Substituir a tentativa por uma escrita sem condição descartaria justamente a proteção. Referência: escritas condicionais.

Uma chave não é uma transação de tabela

Consistência forte e condição sobre um objeto não tornam vários objetos uma transação única. Um relatório formado por dados.parquet e indice.json ainda precisa de uma regra para publicar um par coerente. Iceberg aplica um protocolo específico para publicar conjuntos de arquivos como versões de tabela.

Caso prático

Um cliente envia um vídeo grande. O backend registra um upload pendente e só o marca como pronto depois de verificar a conclusão e os metadados necessários. Cancelamentos precisam tratar tanto o registro da aplicação quanto as partes que ficaram no S3.

Nesse fluxo, “requisição HTTP terminou”, “objeto foi concluído” e “vídeo foi processado” são estados diferentes. Confundi-los pode mostrar arquivos incompletos à aplicação ou cobrar armazenamento de uploads abandonados.

Aprofundamento aplicado

O estado pendente precisa ser retomável

O cliente deve conservar a identidade do upload e as informações necessárias para concluir suas partes. Se perder a conexão após enviar uma parte, precisa reconciliar o estado em vez de reiniciar sempre todo o arquivo. Após a conclusão, registre a identidade do objeto que a aplicação deve usar.

O checksum valida integridade no escopo definido pelo algoritmo e pela operação. A condição If-Match protege uma decisão baseada no ETag observado; ela não substitui checksum nem permite agrupar arbitrariamente várias chaves em uma transação. Referências: multipart e escritas condicionais.

Exercício: dois clientes leem o mesmo ETag e tentam substituir o objeto. Resultado esperado: após uma alteração que muda o ETag, o segundo reconhece o conflito e não remove a condição para forçar sua escrita.

Relacionado: 1. Amazon S3 · 1. Iceberg por Dentro - Metadados, Snapshots e Commits · S3 Performance e Multipart.

---

Parte de 0. MOC Amazon S3