Blog

Exportação assíncrona: por que o arquivo grande não sai na hora

UNIFOKAL7 min de leituraProduto e integração

Pedir todos os dados e receber o download na hora só funciona com base pequena. O padrão 202, o timeout do proxy, memória em fluxo e o link expirável.

No começo, exportar dados é um endpoint que devolve um arquivo. O cliente clica, o servidor monta o conteúdo, a resposta sai com o arquivo anexado e todo mundo fica satisfeito. Funciona por meses, às vezes por anos, porque a base é pequena e a montagem leva um segundo.

Depois a base cresce. O mesmo endpoint passa a demorar quinze segundos, depois quarenta, e um dia começa a devolver erro de conexão encerrada sem nenhuma mensagem útil no log da aplicação. O código não mudou; o volume mudou. É o momento em que a exportação precisa deixar de ser uma resposta e passar a ser um trabalho.

Este texto é sobre esse desenho: o padrão de aceitar o pedido e devolver acompanhamento, os limites que quebram a versão síncrona, e os cuidados que aparecem quando o resultado é um arquivo com dado pessoal dentro. Em produtos de verificação de identidade o assunto tem peso extra, porque exportar significa retirar do sistema uma cópia de informação sensível.

O padrão de aceitar agora e entregar depois

A RFC 9110, que consolida a semântica do HTTP, define o código 202 Accepted para exatamente esta situação: a requisição foi aceita para processamento, mas o processamento não terminou. A resposta não carrega o resultado, carrega o compromisso.

Na prática, o pedido de exportação responde imediatamente com 202 e o identificador de um recurso de acompanhamento. Quem pediu consulta esse recurso e recebe o estado do trabalho: em fila, em processamento, pronto ou falhou. Quando fica pronto, o recurso aponta para o arquivo.

Esse desenho tem três virtudes práticas. A conexão HTTP fica curta e previsível, então nada no caminho precisa segurar um socket aberto por minutos. O estado passa a ser consultável, então uma queda de rede do lado de quem pediu não perde o trabalho já feito. E a falha ganha lugar para morar: em vez de um erro genérico de conexão, o recurso de acompanhamento diz que falhou e por quê, o que muda completamente a vida de quem dá suporte. É a mesma inversão descrita em verificação síncrona e assíncrona, aplicada a arquivos em vez de decisões.

Os dois limites que matam a versão síncrona

Antes de mudar o desenho, vale entender o que exatamente quebra, porque os dois limites são de natureza diferente e nenhum deles se resolve com configuração da aplicação.

O tempo limite que corta não é o seu

A tentação recorrente é aumentar o tempo limite da aplicação. Quase nunca funciona. Entre o navegador e o processo que monta o arquivo existe uma pilha de intermediários, cada um com seu próprio limite: balanceador de carga, proxy reverso, rede de distribuição de conteúdo, camada de execução da função. O corte acontece no menor deles, não naquele que você configurou.

Pior: quando o intermediário corta, a aplicação em geral continua trabalhando, gastando memória e banco para produzir um arquivo que ninguém vai receber. O usuário, sem resposta, clica de novo, e agora são dois trabalhos pesados ao mesmo tempo. E a assimetria que engana é esta: a exportação lenta funciona muito bem em desenvolvimento, sem proxy no meio e com trezentas linhas na base. O erro só aparece em produção, com dado real.

Memória constante em vez do arquivo inteiro

Montar a exportação inteira em memória, como uma lista de objetos que depois vira texto, custa bem mais do que o tamanho final do arquivo, porque a estrutura em memória é maior que a representação em texto e ainda existe uma cópia intermediária na serialização. O consumo cresce com o tamanho da base, não com o número de pedidos, e basta um punhado de exportações simultâneas para o processo ser encerrado por falta de memória, derrubando junto todas as outras requisições que ele atendia.

A alternativa é escrever em fluxo: buscar do banco em páginas, converter cada registro e escrever no destino, mantendo em memória apenas o lote atual. O consumo passa a ser constante e independe do tamanho do resultado. Três detalhes ajudam:

  • Paginar por cursor estável, e não por deslocamento, para que inserções durante a exportação não pulem nem dupliquem registros.
  • Escrever direto no armazenamento de objetos, sem passar pelo disco local da instância, que pode ser efêmero e pequeno.
  • Comprimir durante a escrita, porque exportação em formato de texto costuma reduzir bastante e o custo de transferência cai junto.

O link expirável e o download autenticado

Arquivo pronto, começa a segunda metade do problema. O caminho mais fácil é publicar o arquivo em uma URL de leitura pública e mandar o endereço. É também o mais perigoso: uma URL pública que não expira é um vazamento esperando a hora, porque endereços viajam em histórico de navegador, encaminhamento de mensagem, captura de tela e log de intermediário.

O padrão adequado é o mesmo já usado no sentido contrário, quando o cliente envia mídia para o sistema: uma URL assinada, com prazo curto de validade, que autoriza uma operação específica sobre um objeto específico. Quem já montou o envio seguro de mídia por URL assinada reaproveita a mecânica inteira, invertendo a direção.

Além do prazo curto, três regras fecham o desenho. O pedido do link deve exigir sessão autenticada, para que só quem tem direito ao arquivo consiga gerar um endereço válido. O arquivo deve ter prazo de vida próprio no armazenamento, apagado automaticamente depois de alguns dias, porque ele é uma cópia adicional de dado pessoal fora do perímetro habitual. E o transporte deve ser cifrado, com TLS na versão especificada pela RFC 8446, além da cifragem em repouso do próprio objeto.

Vale insistir no ponto da cópia. Antes da exportação, o dado estava num banco com controle de acesso, trilha e política de retenção. Depois dela, existe um segundo objeto, com outro caminho de acesso, que precisa herdar as mesmas garantias. Exportação sem prazo de expurgo cria um repositório paralelo de dado pessoal.

O que o titular tem direito a receber

Na Lei 13.709/2018, a LGPD, o artigo 18 lista os direitos do titular, entre eles a confirmação da existência de tratamento, o acesso aos dados e a portabilidade a outro fornecedor de serviço ou produto, mediante requisição expressa, de acordo com a regulamentação da autoridade nacional e observados os segredos comercial e industrial. O artigo 19 trata da forma e do prazo de resposta ao pedido de confirmação e acesso, prevendo resposta em formato simplificado de imediato ou, por meio de declaração clara e completa, em até quinze dias contados da requisição.

A distinção entre acesso e portabilidade tem consequência técnica direta. O pedido de acesso é para uma pessoa ler: o formato pode ser legível, organizado por assunto, com rótulos em português e explicação do que cada campo significa. A portabilidade tem como destino outro fornecedor, e portanto pede formato estruturado e interoperável, pensado para ser importado por outro sistema. Tratar os dois como o mesmo arquivo resulta em um despejo técnico que a pessoa não entende, ou em um relatório bonito que nenhum sistema consegue ler. As implicações operacionais desses pedidos aparecem com mais detalhe em direitos do titular em verificação de identidade.

Avisar quando ficar pronto, sem mandar o arquivo junto

Como o trabalho é assíncrono, alguém precisa ser avisado no fim. E-mail resolve, com uma armadilha: mandar o arquivo como anexo.

Anexo é o caminho errado por vários motivos ao mesmo tempo. Ele copia dado pessoal para uma caixa postal, onde fica indexado e replicado por tempo indeterminado, fora de qualquer política de retenção sua. Não tem como expirar depois de enviado. Não confirma que quem abriu a mensagem é quem pediu a exportação, já que caixas são compartilhadas, encaminhadas e comprometidas. E esbarra em limites de tamanho que fazem justamente as exportações grandes falharem em silêncio.

O aviso correto é curto: o arquivo está pronto, entre na sua conta para baixar. O acesso acontece depois de autenticar, o link tem prazo, e o registro de quem baixou e quando fica na trilha, do lado onde ele pode ser auditado.

Fontes citadas