Sidekiq sob pressão: filas, retries e o que aprendi processando milhares de jobs

Quem trabalha com Ruby on Rails sabe que o Sidekiq é quase um membro da família. Ele é rápido, eficiente e, emparelhado com o Redis, resolve o processamento assíncrono de 90% das aplicações sem reclamar.

O problema é que o Sidekiq é tão bom que a gente começa a jogar tudo lá dentro. Envio de e-mail? Sidekiq. Webhooks de terceiros? Sidekiq. Relatórios pesados? Sidekiq. Sincronização de estoque? Sidekiq.

Tudo vai bem no ambiente de desenvolvimento. Mas quando o sistema escala, o volume aumenta e você começa a processar milhares (ou milhões) de jobs por dia, a máquina começa a chiar. Seus workers travam, a memória do Redis vai para o espaço e a fila de Retries vira um cemitério de jobs zumbis.

Depois de quebrar muito a cabeça (e apagar alguns incêndios em produção), aqui estão as principais lições que aprendi para manter o Sidekiq sob pressão sem perder os cabelos.

## 1. O Pecado Capital: A Fila default Única

Quando você não configura o Sidekiq, tudo cai na fila default. Isso significa que o e-mail de "Bem-vindo" do seu cliente (que precisa ir em 2 segundos) está disputando espaço com a geração de um relatório em PDF de 500 páginas que demora 10 minutos.

A primeira lição no mundo real é: Segregue suas filas por prioridade e comportamento.

No seu config/sidekiq.yml, a estrutura precisa refletir o peso e a urgência dos seus jobs:

# config/sidekiq.yml
:concurrency: 10
:queues:
  - [critical, 3] # Processa 3 vezes mais jobs daqui
  - [default, 2]
  - [low, 1]

No seu código Rails, você direciona explicitamente os operários para os lugares certos:

# Um job rápido e vital para a experiência do usuário
class SendWelcomeEmailJob < ApplicationJob
  queue_as :critical

  def perform(user_id)
    # ...
  end
end

# Um job pesado que pode rodar de madrugada se precisar
class ExportFinancialReportJob < ApplicationJob
  queue_as :low

  def perform(account_id)
    # ...
  end
end

## 2. A Armadilha do Retry Infinito (e o Backoff Exponencial)

Por padrão, o Sidekiq tenta reprocessar um job que falhou 25 vezes. Com o algoritmo de backoff padrão, isso significa que um job quebrado vai ficar vagando pelo seu Redis por quase 20 dias antes de ir para a Dead Letter Queue (Morgue).

Se uma API externa (como o Mercado Livre ou a Shopee) cai e você tem 10.000 jobs batendo nela, todos vão falhar e entrar em retry. Em poucas horas, seu Sidekiq estará reprocessando milhares de jobs fadados ao fracasso, gerando um efeito bola de neve.

No mundo real, a gente limita isso e limpa o terreno:

class IntegrarPedidosShopeeJob < ApplicationJob
  queue_as :default

  # Limita para 5 tentativas. Se falhar 5 vezes, chega de gastar CPU.
  sidekiq_options retry: 5

  def perform(order_id)
    # Lógica de integração
  end
end

Se o erro for um clássico HTTP 429 (Too Many Requests), você não quer esperar o tempo padrão do Sidekiq. Você pode customizar o intervalo de retry para dar um respiro para a API parceira.

## 3. Monitorando a Pressão via CLI (Gente grande não usa só o Dashboard Web)

O dashboard web do Sidekiq (/sidekiq) é lindo, mas quando o servidor está engasgando ou você está logado via SSH direto no servidor de produção, a linha de comando é sua melhor amiga.

Abaixo estão os comandos essenciais para você diagnosticar o Sidekiq sob pressão:

### Verificando o tamanho das filas no Redis

Antes de abrir qualquer interface, você pode perguntar direto para o Redis (via redis-cli) como está a saúde das filas. Os jobs do Sidekiq ficam salvos em estruturas de dados do tipo List ou Sorted Set:

# Verifica quantos jobs estão na fila 'critical' aguardando processamento
$ redis-cli LLEN "queue:critical"
(integer) 1542

# Verifica quantos jobs estão na fila de Retries (aguardando a próxima tentativa)
$ redis-cli ZCARD "retry"
(integer) 8432

Se o número do LLEN estiver subindo sem parar, seus workers não estão dando conta do volume. É hora de escalar horizontalmente (adicionar mais pods/instâncias do Sidekiq) ou aumentar a :concurrency:.

### O pulo do gato: Enviando sinais de sistema (Signals)

Se um processo do Sidekiq travou ou você precisa fazer um deploy sem derrubar os jobs no meio da execução, você usa sinais Unix.

# Encontra o ID do processo (PID) do Sidekiq ativo
$ ps aux | grep sidekiq

# Envia o sinal TSTP (Quiet) para o Sidekiq
# Ele para de puxar novos jobs das filas, mas termina os que já começou. Ideal para deploys limpos!
$ kill -TSTP <PID>

# Se o worker travou de vez em um loop infinito, força o encerramento (ele joga o job atual de volta pra fila)
$ kill -TERM <PID>

## 4. Jobs Idempotentes: O Santo Graal

Se você guardar apenas uma lição deste artigo, que seja esta: Seu job vai rodar duas vezes.

Pode ser porque o banco de dados oscilou, porque a rede caiu bem na hora do ack ou porque você deu um kill -TERM no processo. Se o seu job faz algo como "cobrar o cartão de crédito do cliente", rodar duas vezes significa que você vai cobrar o cliente duas vezes.

Jobs em produção precisam ser idempotentes. Antes de executar a ação principal, verifique se ela já foi feita.

class ProcessarPagamentoJob < ApplicationJob
  queue_as :critical
  sidekiq_options retry: 3

  def perform(faturamento_id)
    faturamento = Faturamento.find(faturamento_id)

    # Se já foi pago, encerra o job imediatamente com sucesso
    return if faturamento.pago?

    # Só processa se o status for pendente
    GatewayPagamento.cobrar!(faturamento)
    faturamento.update!(status: :pago)
  end
end

## Conclusão

Processar milhares de jobs por dia com Rails, Sidekiq e Redis não é sobre não ter erros. Erros vão acontecer. As APIs dos marketplaces vão cair, o banco de dados vai dar timeout e a rede vai oscilar.

A diferença entre um sistema resiliente e um sistema caótico está em como você desenha suas filas, como gerencia os retries e no quanto suas tarefas estão prontas para falhar e recomeçar sem corromper os dados.

Configure suas prioridades, limite seus retries, fique de olho no redis-cli e garanta que seus jobs sejam idempotentes. Seu sono no final de semana agradece.