O que é changed download e por que você provavelmente não precisa disso ainda
A ideia básica por trás de changed download (ou download diferencial) é simples: em vez de baixar um arquivo inteiro toda vez que algo muda, você baixa apenas as partes que foram alteradas desde a última execução. O conceito existe há décadas e é usado em coisas como sistemas de backup, sincronização de repositórios e distribuição de patches. Mas a prática é bem mais bagunçada do que a teoria.
Como changed download funciona na prática
Você precisa de três coisas: um identificador único para cada versão do arquivo (normalmente um hash SHA-256), um índice que mapeie quais blocos ou seções foram modificados entre versões, e um algoritmo de diferença. O padrão mais comum é o rsync algorithm, que usa checksums parciais para encontrar blocos alterados sem precisar comparar o arquivo inteiro byte a byte. Ferramentas como rclone, borgbackup e até o próprio git implementam variações disso. O fluxo real é o seguinte: você baixa o índice da versão atual, calcula os hashes dos blocos que já tem localmente, envia esses hashes para o servidor, e o servidor responde com uma lista dos blocos faltantes ou modificados. Você baixa só isso. Se o arquivo mudou muito, o ganho desaparece. Se não mudou nada, você baixa zero bytes e verifica a integridade pelo hash.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu perdi uns três dias tentando rodar changed download num cenário específico com arquivos de vídeo de 4K em um repositório compartilhado via S3. O problema era que o serviço de storage estava calculando hashes de forma consistente, mas os timestamps das alterações nos metadados tinham um offset de alguns segundos entre as réplicas. O resultado: o algoritmo via mudança a cada execução, mesmo quando o conteúdo não tinha alterado. A solução foi forçar a leitura dos metadados da primary region e usar apenas o hash como fonte da verdade, ignorando completamente timestamps. Isso reduziu o tempo de sincronização de cerca de 40 minutos por dia para algo em torno de 3 minutos. A parte que ninguém conta: changed download não é uma bala de prata. Ele depende criticalmente de dois fatores que você nem sempre controla. O primeiro é a estabilidade do índice de versões. Se o serviço que gera os diffs não versionar corretamente, você pode acabar aplicando um patch em cima de uma base errada e corromper o arquivo sem nem perceber. O segundo é o overhead de rede para o handshake inicial. Em links lentos ou com latência alta, o tempo gasto negociando quais blocos baixar pode ser maior do que o tempo de baixar o arquivo inteiro de novo.
Outro detalhe prático que os tutoriais não mencionam: a granularidade dos blocos importa demais. Blocos pequenos (como 16KB) geram mais overhead de metadados e usam mais CPU para calcular hashes. Blocos grandes (256KB ou mais) economizam processamento mas fazem o differential parecer menor do que realmente é quando há muitas mudanças dispersas. Para arquivos pequenos, abaixo de 50MB, changed download quase nunca vale a pena. O overhead de negociação supera qualquer economia. Se o seu caso é simples — baixar updates de algum software ou sincronizar arquivos entre duas máquinas — ferramentas como rclone sync com a flag --checksum ou rsync resolvem o problema sem você precisar montar nada. Eles já implementam changed download por baixo dos panos. Se você precisa de algo mais robusto para backups, o borgbackup é mais confiável porque usa deduplicação baseada em conteúdo com criptografia, não apenas diffs de arquivo completo.
O link para quem quer testar something básico: o rclone é open source, rodando em Linux, Windows e macOS, e cobre 90% dos cenários de changed download que gente encontra no dia a dia. O problema real é quando você tenta implementar changed download do zero. Parece fácil até você encontrar o edge case em que o servidor envia um bloco corrompido e o cliente aceita porque o hash parcial bate. Aí você passa duas horas debugando um arquivo que parece intacto mas tem um byte errado no meio. A recomendação é: use biblioteca existente, teste com dados reais antes de colocar em produção, e sempre valide o hash final após a aplicação dos diffs.
