Workflows que ficam cada vez mais lentos conforme o volume de dados cresce

É um padrão clássico de crescimento: um workflow é construído para processar algumas dezenas de registros por execução, funciona bem, e a operação passa a confiar nele. Meses depois, o volume de dados triplicou, e o mesmo workflow que levava três minutos agora leva vinte e cinco — ou simplesmente trava, sem terminar.

O problema quase nunca está na lógica de negócio do workflow. Está em duas decisões de arquitetura tomadas quando o volume era pequeno e nunca revisadas: como o workflow busca os dados de origem (com ou sem paginação) e como ele os processa (item por item, em série, ou em lotes).

Por que isso acontece

Buscar dados de uma API sem paginação funciona perfeitamente até o dia em que a lista de origem ultrapassa o limite que a própria API aceita retornar de uma vez — nesse momento, o workflow passa a processar apenas uma fração dos dados, silenciosamente, ou falha ao tentar carregar um volume grande demais em uma única chamada.

Processamento estritamente sequencial tem um problema parecido: se o workflow faz uma chamada de API para cada item de uma lista, um por vez, o tempo total de execução cresce linearmente com o volume de dados. Mil itens a um segundo cada já são dezesseis minutos só de espera de rede, sem contar o processamento em si — e esse tempo só aumenta conforme a lista de origem cresce.

A solução: paginar por cursor e processar em lotes

Paginação baseada em cursor — em vez de carregar a lista inteira de uma vez, o workflow busca um lote por vez, usando um identificador do último registro processado para buscar o próximo lote — mantém o volume de dados em memória sob controle, independentemente de a lista de origem ter cem ou cem mil registros.

Processamento em lotes controlados — dividir a lista em grupos menores e processá-los com paralelismo limitado, em vez de todos de uma vez ou um por um — costuma reduzir o tempo total de execução de forma expressiva, sem sobrecarregar a API de destino a ponto de esbarrar em limites de taxa.

As duas técnicas resolvem problemas diferentes e geralmente aparecem juntas: paginação por cursor controla quanto dado entra no workflow de cada vez; processamento em lotes controla quão rápido esse dado é processado depois de já estar dentro do workflow.

EXEMPLO APLICADO

Uma automação de sincronização de catálogo de produtos entre um ERP e uma loja online foi construída quando o catálogo tinha pouco mais de duas mil itens, buscando a lista inteira em uma única chamada e processando um item de cada vez. Um ano depois, com o catálogo em vinte mil itens, a execução ultrapassava o tempo limite configurado e era interrompida no meio, deixando parte dos produtos desatualizados. A correção não exigiu reescrever a lógica de negócio: bastou trocar a busca única por paginação com cursor e agrupar o processamento em lotes de cem itens, com paralelismo controlado — o tempo total caiu de mais de vinte minutos, quando chegava a terminar, para menos de quatro.

 

Como saber se o workflow já chegou nesse ponto

O sinal mais claro é o tempo de execução crescendo de forma desproporcional ao crescimento do volume de dados — se os dados dobraram e o tempo de execução triplicou, a arquitetura do workflow, não o volume em si, é o gargalo. Vale revisar qualquer workflow que já tenha ultrapassado alguns milhares de registros por execução e ainda não tenha paginação nem processamento em lotes configurados.

Sinais de que sua operação tem esse problema

• Existe algum workflow hoje que busca uma lista inteira de dados em uma única chamada, sem paginação?
• O tempo de execução de alguma automação cresceu de forma desproporcional ao crescimento do volume de dados nos últimos meses?
• Alguma automação já chegou a ser interrompida por limite de tempo antes de terminar de processar todos os registros?
• Existe processamento item a item onde um agrupamento em lotes reduziria drasticamente o número de chamadas de rede?

Para concluir

Performance raramente é um problema até o volume de dados passar de determinado ponto — e, quando passa, costuma ser tarde demais para ser um ajuste tranquilo. Revisar paginação e processamento em lotes antes que o volume force essa revisão em regime de urgência é uma das manutenções mais baratas que uma operação de automação pode fazer.