Design de Sistema de Upload e Processamento de Arquivos

O problema

Upload de arquivo parece simples enquanto o arquivo é pequeno e o trabalho depois dele é leve.

Quando o sistema precisa lidar com:

• vídeo grande
• transcodificação
• OCR
• análise de imagem
• geração de relatório

A implementação “recebe no servidor e responde quando terminar” deixa de ser viável muito rápido.

Modelo mental

Aqui existem dois fluxos diferentes:

1. enviar o arquivo
2. processar o arquivo

Misturar os dois no mesmo request costuma ser a raiz do problema.

O desenho saudável normalmente separa:

• upload para storage
• confirmação de chegada
• fila de trabalho
• worker de processamento
• atualização de status

Se quiser uma frase simples:

O usuário não precisa esperar o processamento terminar para o sistema continuar trabalhando.

Quebrando o problema

Tire o arquivo grande do backend principal

O navegador pode pedir ao backend uma URL assinada temporária e fazer upload direto para object storage.

Em linguagem simples:

• o backend autoriza
• o browser envia direto para o storage
• o servidor principal não vira túnel de arquivo gigante

Isso também reduz o risco de estourar CPU, memória e banda do serviço que deveria cuidar só de autorização e estado.

Desacople processamento do request

Quando o arquivo chega, o trabalho pesado não deveria depender do request original ainda estar vivo.

O normal é publicar evento ou job para:

• fila
• worker
• pipeline de processamento

Dê um jeito de o usuário acompanhar status

O cliente não pode ficar preso esperando no request original.

Então o sistema precisa expor algo como:

• PENDING
• PROCESSING
• DONE
• FAILED

Isso pode ser consultado por:

• polling
• webhook
• canal em tempo real

O importante é o usuário ter visibilidade honesta do andamento, e não um loading infinito sem explicação.

Pense em arquivo grande e conexão ruim

Arquivo muito grande costuma pedir upload em partes.

Isso ajuda porque:

• permite retomar depois de falha
• evita recomeçar do zero
• funciona melhor em rede instável

Segurança não entra no fim

Nem todo arquivo recebido deve ser processado.

Antes do trabalho pesado, normalmente entram:

• validação de tipo
• tamanho máximo
• verificação de assinatura
• checagem de segurança

Dependendo do cenário, também entra quarentena antes de liberar o arquivo para consumo interno ou download.

Exemplo simples

Uma resposta madura poderia soar assim:

Vou separar upload de processamento. O cliente pede uma URL assinada ao backend e sobe o arquivo direto para object storage. Quando o upload termina, o storage ou o backend publica um evento para fila. Workers processam o arquivo de forma assíncrona e atualizam um registro de status. O frontend acompanha esse status por polling. Se o arquivo for muito grande, eu uso upload em partes para permitir retomada. Também valido tipo e tamanho antes de iniciar processamento.

Essa resposta cobre:

• caminho do arquivo
• desacoplamento do request
• fila
• retorno de status
• segurança básica

Erros comuns

• Fazer o upload passar inteiro pelo backend sem necessidade.
• Processar dentro do request.
• Não pensar em retomada de upload grande.
• Ignorar validação e segurança do arquivo.
• Entregar resultado sem política de expiração ou reprocessamento.

Como um senior pensa

Quem tem mais experiência costuma fazer esta pergunta cedo:

O usuário precisa esperar o processamento ou só precisa saber que o sistema recebeu o arquivo e vai continuar o trabalho?

Quando a resposta é a segunda, o desenho fica muito mais claro.

Porque boa parte da complexidade deixa de ficar presa ao request inicial.

O que o entrevistador quer ver

Nesse cenário, o entrevistador mede se você:

• separa upload de processamento
• sabe por que object storage entra cedo
• usa fila e worker com critério
• pensa no retorno de status para o usuário
• lembra de validação e segurança

Sistema de upload maduro não segura o usuário olhando para uma barra eterna. Ele divide o fluxo em etapas que o sistema e o usuário conseguem acompanhar.

Quando você separa envio de processamento, o sistema fica mais escalável e a experiência do usuário fica mais honesta.