Handling Sidekiq backpressure on Kubernetes

Handling Sidekiq backpressure on Kubernetes

Filas Sidekiq podem crescer rápido quando jobs são mais lentos que a entrada. Em clusters Kubernetes, é fácil escalar errado e piorar o problema.

Um playbook enxuto para estabilizar:

Sintomas

• Fila subindo mesmo com HPA ativo.
• Pods reiniciando por OOM.
• Jobs duplicados ou expirando em reprocesso.

Ações imediatas

1) Separar filas por criticidade
Use múltiplos Deployments com --queues critical,default e --queues low. Evita que jobs lentos bloqueiem críticos.

2) Autoscaling por latência, não por CPU
Métrica recomendada: tempo em fila ou queue latency. Configure KEDA/HPA lendo métricas do Redis ou Prometheus.

3) Memory requests/limits realistas
Meça uso com sidekiq_exporter + process_resident_memory_bytes. Ajuste limites para evitar OOMKills em picos.

4) Batch menor e idempotência
Reduza tamanho de lotes e valide idempotência dos workers. Reprocessos não devem causar efeitos colaterais.

5) Dead letter clara
Direcione falhas para uma fila de retry ou dead com retenção curta e alertas.

Observabilidade mínima

• Exportar queue_latency, processed, failed, busy por queue.
• Alertar quando queue_latency > SLO definido (ex.: 30s para critical).
• Logar payload essencial para reprocesso, sem dados sensíveis.