Dimensionando com Airflow 3.2: Quando Postergar e Quando Usar Operadores Assíncronos Nativos

O Airflow 3.2 não é só mais uma atualização incremental: ele resolve um gargalo antigo de arquitetura, a pressão no triggerer e no banco de metadados, ao trazer execução assíncrona nativa para o PythonOperator, sem exigir que o usuário gerencie event loops ou migre para operadores deferíveis. Isso muda o jogo para pipelines de micro-batch com centenas ou milhares de chamadas concorrentes (APIs, SFTP, webhooks), onde antes cada tarefa consumia um slot completo de worker e passava pelo ciclo completo de agendamento/triggerer/execução. Agora, dentro de um único slot, múltiplas operações de I/O podem rodar em paralelo sob o mesmo event loop, reduzindo drasticamente latência e uso de recursos. A combinação com Dynamic Task Mapping, estável desde a versão 2.3, permite que essa concorrência seja orquestrada dinamicamente, com base em dados reais do runtime, sem pré-definição estática de tarefas.

Essa mudança não é só técnica: ela desloca o custo de escalabilidade do lado da infraestrutura (mais workers, mais triggerers) para o lado da lógica de código, onde os engenheiros de dados já operam. O suporte a asset partitions, também novo na 3.2, complementa isso ao permitir respostas granulares a eventos de dados, não apenas a gatilhos temporais. Juntos, os dois recursos sinalizam uma virada clara: o Airflow está migrando de uma ferramenta de agendamento cronológico para um sistema de reação a eventos de dados, com controle preciso de dependências entre ativos.

Para times que rodam pipelines com alta frequência de I/O, como ingestão de APIs externas, sincronização de sistemas legados ou processamento de lotes pequenos mas numerosos, o ganho não é marginal. Testes internos da Astronomer com carga de 5.000 requisições HTTP mostraram redução de 78% no tempo total de execução e queda de 92% na carga no banco de metadados, comparado à abordagem com operadores deferíveis. Isso significa menos instâncias de triggerer, menor custo operacional e maior previsibilidade no SLA de DAGs críticos. Além disso, eliminar a dependência do triggerer simplifica a implantação, especialmente em ambientes com restrições de rede ou compliance rigoroso, onde expor o componente triggerer era um ponto fraco de segurança.