Migrando filas do Redis de List para Sorted Set (ZSet)
O disparo em massa de campanhas usava listas do Redis (LPUSH/RPOP). Funcionava,
mas não dava o controle de prioridade e paralelismo que múltiplas lojas exigiam.
Por que ZSet
Com Sorted Set cada item carrega um score. Isso abre:
- Prioridade real por score (urgência, horário de envio, tier do número).
- Processamento paralelo por faixas de score, sem um worker pisar no outro.
- Janelas de tempo naturais para agendamento.
ZADD fila:loja:42 1718000000 "msg:abc"
ZRANGEBYSCORE fila:loja:42 -inf <agora> LIMIT 0 100
Resultado
Throughput mais alto entre várias lojas ao mesmo tempo e fim dos timeouts de conexão com o PostgreSQL que apareciam no fluxo de enriquecimento, combinando ZSet com locks distribuídos no Redis.
A lição: a estrutura de dados certa no lugar certo vale mais que mais máquinas.
Mass campaign dispatch used Redis lists (LPUSH/RPOP). It worked, but it didn’t
give the priority and parallelism control that multiple stores needed.
Why ZSet
With a Sorted Set, each item carries a score. That unlocks:
- Real priority by score (urgency, send time, number tier).
- Parallel processing by score ranges, without workers stepping on each other.
- Natural time windows for scheduling.
ZADD queue:store:42 1718000000 "msg:abc"
ZRANGEBYSCORE queue:store:42 -inf <now> LIMIT 0 100
Result
Higher throughput across many stores at once, and the end of the PostgreSQL connection timeouts that showed up in the enrichment flow, by combining ZSet with distributed locks in Redis.
The lesson: the right data structure in the right place beats throwing more machines at the problem.