A Netflix reformulou o Conductor, seu motor de orquestração de workflows distribuídos, para dar conta de um crescimento que já beira o desconfortável: são cerca de 200 mil definições de workflow espalhadas por 150 aplicações, executando aproximadamente 420 milhões de workflows por mês. Com a versão 4.0, a empresa aumentou o tamanho máximo suportado de um workflow de cerca de 2.500 para 30 mil tarefas (um salto de mais de 10x) e reduziu a latência p99 de avaliação de workflow em cerca de 40%.
Para quem constrói sistemas de orquestração, pipelines de dados ou qualquer coisa que coordene tarefas de longa duração entre serviços, o interessante aqui não é o número gigante da Netflix, é a natureza do gargalo que eles bateram e como resolveram. É um caso de estudo sobre o que quebra quando o tamanho de cada unidade de trabalho cresce, não só o volume.
Onde o motor emperrava
O Conductor orquestra fluxos distribuídos nas áreas de Content e Studio Engineering, Ads e Games da Netflix. A stack já tinha passado por várias trocas de peças ao longo dos anos: migração dos dados de execução de Dynomite para Cassandra, movimentação de inputs e outputs grandes de tarefas para o Amazon S3, substituição do DynoQueues pelo Timestone, e a entrada do Kafka para desacoplar a indexação do caminho de execução, com Elasticsearch e Iceberg cuidando de indexação e armazenamento de longo prazo.
Mesmo assim, sobrou um gargalo: a avaliação do workflow. Nas versões anteriores, o Conductor carregava o estado completo do workflow em memória a cada avaliação. Isso funciona bem quando os fluxos são pequenos, mas vira um problema à medida que eles crescem, porque a pressão de memória escala junto com o tamanho de cada workflow.
Esse não era um problema teórico. Discussões antigas da comunidade já tinham exposto o sintoma. Em 2022, um usuário relatou que 55.745 workflows e 310 mil tarefas empurravam o uso de heap da JVM para 5 GB. Aravind Ramkumar, mantenedor do Conductor na Netflix, explicou na época que o motor carregava o workflow inteiro em execução na memória para avaliá-lo, e que carregar apenas as partes necessárias estava no roadmap. Outra discussão descreveu um workflow de 1,7 MB com quase 5 mil entradas de tarefa: só armazenar a definição levava perto de dois minutos, e recarregá-la repetidamente do banco afetava o tempo de execução.
A decisão de arquitetura central
A mudança de fundo no Conductor 4.0 é separar metadados do workflow dos dados de tarefa e de usuário, armazenando as tarefas de forma independente. Em vez de carregar o estado inteiro, o avaliador passa a trabalhar com um blueprint leve do workflow e carrega apenas os dados da tarefa necessários para tomar a próxima decisão.
É a diferença entre abrir o arquivo inteiro para ler uma linha e ter um índice que aponta direto para o pedaço que importa. Quando o workflow tem 30 mil tarefas, carregar só o que a próxima decisão exige em vez de tudo é o que torna esse tamanho viável sem estourar a memória.
Tirando o lock e a avaliação do caminho síncrono
Dois outros movimentos atacam contenção. O primeiro remove o locking da coordenação de estado das tarefas: os estados pending e terminal passam a ser armazenados separadamente e reconciliados na camada de aplicação, com o estado terminal tendo precedência. O segundo tira a avaliação do workflow do caminho síncrono de request, colocando as atualizações em filas exclusivas do Timestone para processamento assíncrono e sequencial.
O resultado reportado é direto: as tentativas falhas de aquisição de lock, que chegavam a cerca de 2.700 por intervalo em momentos de contenção, caíram para essencialmente zero.
| Métrica | Antes | Depois (4.0) |
|---|---|---|
| Tamanho máximo do workflow | ~2.500 tarefas | ~30.000 tarefas |
| Latência p99 de avaliação | referência | ~40% menor |
| Falhas de aquisição de lock por intervalo | ~2.700 | ~0 |
| Workflows executados por mês | ~420 milhões |
Escala é horizontal, não polling mais agressivo
Uma lição recorrente nas discussões da comunidade vale destacar porque contraria um instinto comum. Um usuário relatou entre 25 mil e 30 mil workflows em execução com filas de tarefas HTTP se acumulando. A tentação natural é aumentar a frequência de polling dos workers. Segundo relato da fonte, Aravind Ramkumar recomendou o contrário: aumentar as contagens de polling não melhoraria o processamento e poderia sobrecarregar o sistema, sendo preferível escalar horizontalmente.
É o tipo de armadilha em que qualquer time que opera workers cai: quando a fila cresce, pisar no acelerador do polling costuma piorar a contenção, não resolvê-la. Adicionar mais workers em paralelo é o caminho.
O que vem no pacote 4.0
Além das mudanças de arquitetura, o Conductor 4.0 adiciona controles nativos de concorrência, alocação dinâmica de workers e um SDK de workflow em Java↳Java42 conteúdosNovidades do Java 26 (para desenvolvedores)Dev (Back & Front) · mar 2026Visual Studio Code para Java: o guia completo (dicas, configuração e extensões)Dev (Back & Front) · out 2025Quarkus: Modernizando a linguagem Java para a era da nuvemDev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) → type-safe, já usado pela Netflix Ads para ingestão de peças criativas e para workflows de Data Clean Room. O motor mantém a abordagem de orquestração baseada em tarefas, com definições de workflow e um motor de execução separado, mirando fluxos distribuídos de longa duração.
A Netflix projeta que a demanda por workflows pode crescer até cinco vezes conforme a empresa avança em áreas como conteúdo ao vivo, games e podcasts, o que ajuda a entender por que investir agora em suportar fluxos 10x maiores.
O detalhe que muda quem pode usar
Aqui vai o ponto de atenção para times brasileiros que consideraram o Conductor como base de orquestração. A Netflix descontinuou a manutenção do repositório público do Conductor OSS em dezembro de 2023, citando a migração para seu fork interno. Ou seja: todas essas melhorias descritas rodam na versão interna da Netflix, e não há garantia de que cheguem ao código aberto.
O que permanece disponível são os módulos e extensões contribuídos pela comunidade, mantidos em um repositório separado. Na prática, quem depende do Conductor OSS hoje precisa considerar o cenário de manutenção comunitária antes de apostar em produção. As decisões de design contadas pela Netflix (separar blueprint de dados de tarefa, tirar avaliação do caminho síncrono, reconciliar estado na aplicação em vez de lock) são replicáveis em qualquer motor de orquestração próprio, e talvez seja aí que esteja o maior valor deste relato: não no código pronto, mas no mapa dos gargalos que aparecem quando o tamanho de cada workflow, e não só o número deles, cresce.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
Comentários
Ninguém comentou ainda. Começa a conversa?