Dê aos workers em segundo plano um orçamento limitado

Defina uma unidade de trabalho útil

Para uma exportação CSV interna, uma requisição cria um registro de exportação; um worker lê um conjunto de dados limitado, grava um objeto de saída e marca o registro como concluído. Defina o escopo útil máximo, o limite de tempo e o comportamento de cancelamento. Use uma fila isolada, banco de dados de teste e destino que não possa notificar clientes reais.

Separe o tempo de computação da espera por banco de dados e armazenamento. Um único número de duração do job esconde essas distinções. Construir o arquivo inteiro em memória escala de forma diferente de transmitir lotes limitados. Mantenha a mensagem da fila pequena o suficiente para descrever o trabalho sem incorporar dados de clientes ou uma credencial.

Torne a entrega repetida segura por design

Use um identificador de exportação durável para relacionar tentativas a um único resultado lógico. Imponha unicidade e uma transição atômica de propriedade/conclusão em estado durável. Verificar se uma exportação existe e depois inserir em uma etapa separada e desprotegida permite que tentativas concorrentes corram em condição de corrida. Publicar um objeto e confirmar a mensagem da fila também formam um limite de falha.

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery associa confirmação tardia com tarefas idempotentes e documenta casos em que a confirmação ainda acontece após a terminação do processo filho. Uma opção de fila não cria execução exatamente uma vez. Revise as semânticas de reentrega do seu sistema e projete o resultado da aplicação para tolerar retentativas.

Referência técnica: Comportamento de tarefas do Celery.

Defina o orçamento antes de aumentar os processos

Para um worker hipotético usando 300 MiB por exportação ativa, quatro exportações simultâneas já implicam cerca de 1,200 MiB antes da sobrecarga de runtime. Essas são entradas de planejamento, não benchmarks. Adicione conexões de banco de dados, memória de consulta, disco temporário e largura de banda de saída; uma contagem de processos é apenas um limite.

Ensaie com uma exportação ativa e um backlog realista. Aumente para duas enquanto repete o mesmo tráfego de API. Compare exportações úteis concluídas, idade do job mais antigo, latência, falhas e pressão no host. Se a taxa de transferência mal melhorar enquanto as esperas do banco de dados crescem, pare de aumentar a concorrência. CPU extra pode não remover esse gargalo.

Impeça que a falha crie mais carga

Classifique os erros antes de tentar novamente. Uma indisponibilidade temporária de armazenamento pode ser transitória; uma conta não autorizada ou um formato de exportação não suportado precisa de um erro terminal ou intervenção. Use um orçamento finito de tentativas e retentativas atrasadas com backoff e jitter onde houver suporte. Mantenha os jobs com falha inspecionáveis com campos sensíveis removidos.

Aplique timeouts a chamadas externas e um orçamento geral de tarefa. Abandonar uma tentativa não prova que seu efeito colateral remoto não ocorreu. Uma publicação que expirou pode já ter escrito a saída. Reconcilie pelo ID de exportação em vez de publicar outro resultado às cegas.

Inclua os workers na implantação e na recuperação

Pare novos trabalhos no worker antigo usando seu comportamento de desligamento documentado. Deixe o trabalho em andamento terminar ou interrompa-o com segurança sob um prazo conhecido. Teste uma falha após a saída ser escrita mas antes da conclusão ser registrada; a tentativa de substituição deve encontrar um resultado consistente em vez de duplicá-lo.

Mantenha os formatos de mensagem compatíveis entre versões sobrepostas. Uma nova API pode enfileirar um payload que um worker antigo não consegue ler. Versione o contrato ou sequencie o lançamento para que consumidores suportados existam antes de novas mensagens aparecerem. Inclua esses escritores de banco de dados na revisão de compatibilidade de schema.

Escolha a próxima restrição a alterar

Deixe uma configuração de concorrência, política de retry, contrato de tarefa e regra de parada medida. Se exportações caras atrasarem trabalhos pequenos, considere filas separadas com orçamentos independentes antes de aumentar o limite global. Se a latência da API sofrer em qualquer carga realista de exportação, separar workers pode ser mais útil do que ampliar um único host compartilhado.

Repita a mesma carga de trabalho após uma mudança e mantenha a comparação. O Cenário de API e workers explica onde App 2 e memória extra entram na escolha. Esses procedimentos não implicam uma fila gerenciada, trabalhos ilimitados ou escalonamento automático.