Node.js travando? Como processar tarefas pesadas sem parar a API

Por que o Node.js trava quando executamos tarefas pesadas?

Quando começamos a programar em Node.js, somos atraídos pela sua velocidade impressionante para lidar com requisições simultâneas. Na prática, isso significa que a plataforma consegue gerenciar milhares de conexões de rede abrindo e fechando portas de comunicação sem sofrer com gargalos comuns em outras tecnologias. No entanto, existe um calcanhar de Aquiles que pega muita gente de surpresa: o modelo de execução baseado em uma única linha principal, o chamado event loop.

Para entender o problema, imagine que o event loop é o caixa único de um mercado de bairro pequeno. Se o cliente da vez compra apenas alguns itens rápidos, a fila anda voando. Mas se chega alguém querendo pagar duzentas contas diferentes e preencher boletos manuais, a fila inteira para. Em termos de software, operações como criptografia pesada, processamento de imagens, compressão de arquivos grandes ou cálculos matemáticos complexos exigem muita energia do processador e travam essa única linha de atendimento. Enquanto o servidor calcula um hash complexo ou converte um vídeo, ele não consegue responder a mais ninguém, gerando latência alta e timeouts irritantes para os seus usuários.

Muitas equipes tentam resolver isso migrando partes do sistema para microsserviços ou reescrevendo tudo em linguagens compiladas, mas a solução para o gargalo muitas vezes já está dentro do próprio ecossistema. Assim como discutimos quando um sistema sofre com gargalos em bancos SQL e precisa de uma distribuição inteligente de carga, o Node.js também exige uma divisão clara de responsabilidades quando a CPU é severamente exigida. O segredo é parar de forçar a linha principal a fazer o trabalho pesado e delegar essas operações para ajudantes dedicados.

Entendendo o papel do Event Loop e o bloqueio de CPU

O coração do Node.js é construído sobre o motor V8 do Google e a biblioteca libuv. Enquanto a libuv cuida de operações de entrada e saída, conhecidas como I/O (como ler arquivos do disco ou buscar dados em um banco de dados) de forma assíncrona usando o sistema operacional, o código JavaScript síncrono roda direto na linha principal. O problema surge quando misturamos operações de I/O rápidas com laços de repetição gigantescos ou algoritmos matemáticos que demoram segundos inteiros para rodar.

Na prática, qualquer código síncrono que leve mais do que alguns poucos milissegundos para terminar vai congelar o servidor. Se um cliente pede para redimensionar uma foto de alta resolução e, no mesmo segundo, outros quinhentos usuários tentam abrir a página inicial do seu site, esses quinhentos usuários terão que esperar o processamento da foto terminar. O servidor não tem como atender dois pedidos ao mesmo tempo se a única linha de raciocínio dele estiver ocupada fazendo contas.

Essa dinâmica de bloqueio difere drasticamente de gargalos em camadas de persistência. Enquanto problemas de banco costumam ser resolvidos com índices ou particionamento, o travamento de CPU exige isolamento computacional. Se você já precisou criar um logger assíncrono em Rust sem travar threads, sabe que o gerenciamento de concorrência é vital para manter a estabilidade do sistema sob pressão severa.

O que são Worker Threads e como elas salvam sua aplicação

Para resolver o problema do bloqueio de CPU sem precisar abandonar o ecossistema JavaScript, o Node.js introduziu o módulo nativo worker_threads. Em termos simples, uma worker thread é uma linha de execução independente que roda em paralelo à linha principal. Enquanto a linha principal continua focada em receber requisições HTTP e entregar respostas rápidas aos clientes, você pode despachar a tarefa pesada para uma worker thread dedicada.

Pense nisso como contratar um funcionário exclusivo para cuidar da contabilidade nos fundos da loja, enquanto o caixa da frente continua atendendo os clientes comuns com total agilidade. A thread principal envia os dados brutos para a worker, que faz todo o trabalho sujo de processamento computacional em um espaço de memória separado e, quando termina, devolve o resultado pronto.

Dessa forma, a latência das suas rotas assíncronas despenca e se mantém estável, independentemente de quantas tarefas pesadas estejam rodando nos bastidores. A arquitetura de workers evita que um único cálculo demorado derrube o servidor inteiro e estrague a experiência de quem está navegando na sua aplicação naquele exato momento.

Implementando computação paralela com código prático

Vamos ver como isso funciona na prática criando um exemplo simples de offloading de tarefas pesadas. Primeiro, criamos o arquivo principal do servidor, que recebe a requisição e a repassa para um arquivo de worker isolado. O código abaixo demonstra como inicializar uma nova thread e aguardar o resultado de forma limpa.

const { Worker } = require('worker_threads');
const http = require('http');

function runHeavyTask(workerData) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./worker.js', { workerData });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0)
        reject(new Error(`Worker parou com o código ${code}`));
    });
  });
}

const server = http.createServer(async (req, res) => {
  if (req.url === '/processar') {
    try {
      const resultado = await runHeavyTask(5000000000);
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ status: 'sucesso', resultado }));
    } catch (error) {
      res.writeHead(500, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ erro: error.message }));
    }
  } else {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('API rapida e responsiva!');
  }
});

server.listen(3000, () => {
  console.log('Servidor rodando na porta 3000');
});

Agora precisamos criar o arquivo worker.js que vai executar o cálculo pesado de forma isolada, garantindo que a linha principal do servidor permaneça totalmente livre para atender novas requisições HTTP enquanto o laço numérico é executado.

const { parentPort, workerData } = require('worker_threads');

function calcularPesado(limite) {
  let soma = 0;
  for (let i = 0; i < limite; i++) {
    soma += i;
  }
  return soma;
}

const resultado = calcularPesado(workerData);
parentPort.postMessage(resultado);

Com essa divisão, o servidor continua respondendo instantaneamente à rota raiz enquanto o cálculo pesado roda em segundo plano na thread dedicada, provando a eficácia do isolamento computacional.

Boas práticas e armadilhas ao usar Worker Threads

Apesar de resolverem o problema do travamento de CPU, as Worker Threads não devem ser usadas de maneira descuidada para qualquer pequena operação. Criar uma nova thread tem um custo de inicialização de memória e tempo de CPU. Se você criar uma thread nova para somar dois números simples, o custo de criação será maior do que o próprio processamento, gerando o efeito inverso de lentidão.

O cenário ideal para utilizar worker threads envolve tarefas que consomem centenas de milissegundos ou segundos inteiros de processamento, como processamento de áudio e vídeo, criptografia pesada, leitura e parsing de arquivos JSON gigantescos ou modelagem matemática. Além disso, vale a pena considerar o uso de um pool de workers — um grupo pré-inicializado de threads reutilizáveis — para evitar o desgaste constante de criar e destruir threads a cada nova requisição que chega ao sistema.

Outro ponto crítico é a comunicação. Como as threads rodam em instâncias de V8 separadas, os dados precisam ser copiados ou transferidos (usando ArrayBuffers) entre a thread principal e a worker. Passar objetos gigantescos constantemente pode gerar consumo excessivo de memória se não for planejado com cuidado. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre IA alucinando? Como criar guardrails no LlamaIndex.

Considerações Finais

Manter uma API assíncrona rápida e responsiva sob alta carga exige compreender os limites físicos do motor de execução da sua linguagem. O Node.js continua sendo uma ferramenta extraordinária para arquiteturas web modernas, desde que você respeite a natureza do seu event loop e saiba delegar o trabalho pesado para o lugar certo.

Ao adotar Worker Threads para isolar operações intensivas de CPU, você protege a experiência do usuário final, evita quedas de serviço e aproveita ao máximo o hardware do seu servidor. O planejamento cuidadoso da concorrência garante escalabilidade sustentável e sistemas resilientes para o futuro.