Filas BullMQ e Redis 7 na Evolution API v3: Como Dimensionar Workers para 20 a 50 Números de WhatsApp Sem Perder Webhooks

O Desafio da Concorrência Assíncrona no WhatsApp em 2027

Em operações profissionais que utilizam o WhatsApp como canal primário de atendimento, vendas e relacionamento, o volume de eventos recebidos não é linear. Um anúncio de alta conversão veiculado no Instagram, um disparo transacional de notas fiscais ou a abertura do expediente comercial às 09h00 da manhã podem gerar rajadas repentinas de 300 a 1.000 mensagens por segundo espalhadas por dezenas de números conectados.

Veja a infraestrutura: VPS para n8n + Evolution API para colocar este projeto no ar.

Na VPS para Evolution API v3, toda essa torrente de dados não atinge diretamente os endpoints externos. Para proteger a integridade do sistema, a aplicação utiliza o BullMQ — a biblioteca de filas baseada em Redis mais avançada e resiliente do ecossistema Node.js. O BullMQ organiza o fluxo em jobs desacoplados: recebimento de pacotes Baileys, processamento de mídias, gravação no PostgreSQL 16 e entrega de webhooks com garantia transacional.

Contudo, quando a infraestrutura não é calibrada corretamente, o Redis e o BullMQ tornam-se o elo fraco da corrente. Perda silenciosa de mensagens de clientes, webhooks duplicados, travamentos aleatórios de instâncias e quedas por falta de memória (OOM Killer) são sintomas clássicos de um Redis mal configurado ou de uma VPS subdimensionada. Neste guia técnico, detalhamos como dimensionar workers, ajustar flags de persistência no Redis 7 e garantir que sua operação com 20 a 50 números nunca perca uma única mensagem.

1. A Anatomia do BullMQ na Evolution API v3

O BullMQ opera no Redis utilizando estruturas de dados nativas de alta performance: Streams, Sorted Sets (ZSETs), Hashes e Lists. Cada fila possui um ciclo de vida estrito para seus jobs:

1. Waiting: A mensagem chega do socket do WhatsApp e o payload do webhook é enfileirado para processamento imediato.
2. Active: Um worker livre assume o job e realiza o disparo HTTP POST para o endpoint configurado (como seu webhook no VPS para n8n ou Chatwoot).
3. Completed: O receptor respondeu com HTTP 200/201 dentro do timeout configurado (geralmente 5 a 10 segundos). O job é marcado como concluído e agendado para remoção automática.
4. Delayed / Retrying: Se o receptor responder com erro 500, timeout ou recusa de conexão, o BullMQ não descarta a mensagem. Ele recalcula o tempo com base na estratégia de backoff exponencial (ex: 2s, 4s, 8s, 16s) e re-enfileira o job.
5. Failed (Dead-Letter): Após esgotar o limite máximo de tentativas (por padrão, 3 a 5 retries), o job é transferido para a fila de falhas permanentes.

Em uma operação com 30 números de WhatsApp recebendo mensagens simultâneas, há constantemente milhares de chaves sendo lidas, atualizadas e excluídas no Redis a cada minuto. Se o Redis estiver configurado com parâmetros padrão de desenvolvimento, o desastre é iminente sob o primeiro pico de tráfego.

2. As Flags Cirúrgicas do Redis 7 no `redis.conf`

O maior erro cometido por equipes de DevOps é rodar o container do Redis com a imagem padrão do Docker sem montar um arquivo de configuração redis.conf customizado. Por padrão, o Redis pode alocar memória até o limite físico do sistema operacional e descartar chaves arbitrariamente quando a RAM atinge o teto.

Abaixo apresentamos as diretivas obrigatórias para ambientes de alta concorrência com WhatsApp:

# /etc/redis/redis.conf otimizado para Evolution API v3

# 1. Política de Memória Mandatória: NUNCA USE VOLATILE-LRU
maxmemory 1536mb
maxmemory-policy noeviction

# 2. Persistência Resiliente com AOF (Append Only File)
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 3. Proteção de Clientes e Buffers de Saída (Evita leak com WebSockets)
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# 4. Concorrência e Threads de I/O no Redis 7
io-threads 4
io-threads-do-reads yes

# 5. Otimização de Latência e Economia de Kernel
tcp-backlog 511
timeout 0
tcp-keepalive 300

Por que a diretiva `maxmemory-policy noeviction` é inegociável?

Em ambientes de cache comuns (como sessões web de e-commerce), se o Redis encher, descartar as chaves menos acessadas (política volatile-lru ou allkeys-lru) é aceitável. No WhatsApp, contudo, as chaves do Redis são as mensagens reais de leads e clientes aguardando processamento.

Se você mantiver a política LRU padrão e sua RAM bater no teto durante um pico de disparos, o Redis começará a apagar silenciosamente os jobs de mensagens que estavam na fila. O cliente envia uma mensagem no WhatsApp, o status fica com dois tracinhos cinzas, mas ela jamais chega ao seu atendente no Chatwoot ou ao robô de inteligência artificial. Com noeviction, o Redis rejeita novas gravações gerando logs claros de erro, permitindo que a aplicação aplique backpressure consciente sem perda de dados históricos.

3. Dimensionamento de Workers para 20 a 50 Números de WhatsApp

A velocidade de drenagem das filas depende diretamente de quantos workers estão ativos e qual o nível de concorrência atribuído a cada um. Na Evolution API v3, cada worker é um processo que monitora as filas de eventos no Redis e despacha as requisições HTTP para os destinos.

Repare que aumentar o parâmetro de concurrency indefinidamente causa o efeito reverso. Se você configurar concorrência 50 em um único worker, esse processo disparará 50 requisições HTTP paralelas contra o seu n8n ou webhook receiver. Se o servidor receptor não aguentar a carga, ele começará a responder com HTTP 504 Gateway Timeout, fazendo o BullMQ re-enfileirar todos os 50 jobs simultaneamente e gerando um ataque de negação de serviço (DDoS) auto-infligido contra sua própria infraestrutura.

4. Por Que Servidores Genéricos de 2GB de RAM Colapsam Sob Pico

Muitos integradores tentam economizar contratando planos básicos de 2GB de RAM em hospedagens genéricas compartilhadas. Essa economia ilusória é a principal causadora de instabilidades no WhatsApp. Vejamos a matemática real de alocação de memória do Linux em uma VPS de 2GB:

• Sistema Operacional (Kernel Linux 6.x + Systemd + SSHD + UFW): consome cerca de 450MB a 550MB de RAM.
• PostgreSQL 16 (shared_buffers + conexões ativas): consome no mínimo 450MB a 600MB de RAM.
• Redis 7 (dataset base + buffers de replicação): consome entre 250MB e 400MB de RAM.

A soma desses três componentes essenciais já atinge 1.550MB de RAM. Isso deixa míseros 450MB livres para a Evolution API v3 em Node.js. No momento em que um lead envia uma mensagem de voz de 1 minuto (cujo áudio em base64 expande o buffer em memória durante o download), a engine V8 do Node.js solicita mais 300MB de heap ao sistema operacional.

Como a memória física esgota e VPS baratas frequentemente desativam o arquivo de swap ou usam discos mecânicos lentos, o mecanismo OOM Killer (Out of Memory Killer) do kernel Linux é ativado imediatamente. O kernel escolhe o processo com maior oom_score — invariavelmente o Node.js ou o Redis 7 — e encerra o container abruptamente com o sinal SIGKILL. A instância do WhatsApp cai, os clientes ficam sem resposta e o integrador gasta horas tentando decifrar o motivo da falha.

5. Docker Compose Completo para 20 a 50 Números com Limites Rigorosos

Para proteger sua infraestrutura contra o OOM Killer, cada container deve ter seus limites de memória (soft e hard limits) estritamente parametrizados no docker-compose.yml. Dessa forma, nenhum processo individual consegue consumir a memória dos demais componentes:

version: '3.8'

services:
  # Banco de Dados de Produção
  postgres:
    image: postgres:16-alpine
    container_name: evolution_postgres
    restart: always
    environment:
      POSTGRES_DB: evolution_v3_db
      POSTGRES_USER: postgres_user
      POSTGRES_PASSWORD: SenhaComplexaPostgres2027
    volumes:
      - postgres_volume:/var/lib/postgresql/data
    networks:
      - evolution_net
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '2.0'
        reservations:
          memory: 512M

  # Redis 7 com Configuração Cirúrgica
  redis:
    image: redis:7-alpine
    container_name: evolution_redis
    restart: always
    command: [
      "redis-server",
      "--maxmemory", "1536mb",
      "--maxmemory-policy", "noeviction",
      "--appendonly", "yes",
      "--appendfsync", "everysec"
    ]
    volumes:
      - redis_volume:/data
    networks:
      - evolution_net
    deploy:
      resources:
        limits:
          memory: 1792M
          cpus: '1.5'
        reservations:
          memory: 512M

  # Evolution API v3 Master
  evolution_api:
    image: atendai/evolution-api:v2.2.2
    container_name: evolution_core
    restart: always
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - NODE_ENV=production
      - SERVER_PORT=8080
      - DATABASE_ENABLED=true
      - DATABASE_CONNECTION_URI=postgresql://postgres_user:SenhaComplexaPostgres2027@postgres:5432/evolution_v3_db
      - CACHE_REDIS_ENABLED=true
      - CACHE_REDIS_URI=redis://redis:6379/1
      - CACHE_REDIS_TTL=604800
      - WEBHOOK_GLOBAL_ENABLED=true
      - WEBHOOK_GLOBAL_URL=http://n8n_core:5678/webhook/evolution-events
      - WEBHOOK_EVENTS_MESSAGE_UPSERT=true
      - WEBHOOK_EVENTS_MESSAGES_UPDATE=true
      - WEBHOOK_EVENTS_CONNECTION_UPDATE=true
      - WEBHOOK_EVENTS_SEND_MESSAGE=true
    depends_on:
      - postgres
      - redis
    networks:
      - evolution_net
    deploy:
      resources:
        limits:
          memory: 2048M
          cpus: '3.0'
        reservations:
          memory: 1024M

volumes:
  postgres_volume:
  redis_volume:

networks:
  evolution_net:
    driver: bridge

6. Conclusão: Escolhendo a Infraestrutura Certa no Brasil

Dimensionar o Redis 7 e o BullMQ com as técnicas detalhadas neste artigo elimina 99% das dores de cabeça com perda de webhooks no WhatsApp. No entanto, o software não opera no vácuo: ter hardware dedicado com virtualização KVM estrita, discos NVMe de alta velocidade e conectividade direta com o IX.br em São Paulo é o alicerce fundamental para a estabilidade do seu negócio.

No mercado nacional, a You Secure consolidou-se como referência entre as Melhores VPS do Brasil, fornecendo planos de alta densidade sem contratos abusivos. Você pode usufruir da política de VPS sem fidelidade no Brasil para validar sua operação com total tranquilidade técnica e financeira.