System Design/04 - Cloud Design Patterns/Messaging2 min
Queue-Based Load Leveling
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Colocar uma fila entre produtor e consumidor para que o pico de chegada não vire pico de carga no processamento.
carga sem fila: ▁▁▇█▇▁▁▁█▇▁ o serviço vê o pico
carga com fila: ▃▃▃▃▃▃▃▃▃▃▃ o serviço vê a média
O serviço processa no ritmo que aguenta; a fila guarda o excedente durante o pico e esvazia no vale.
Trade-offs
O ganho é poder dimensionar pela carga média em vez da carga de pico — o que costuma significar uma fração do custo de infraestrutura. E o pico deixa de causar erro: ele causa espera.
Os custos:
| Custo | Detalhe |
|---|---|
| Latência | A resposta deixa de ser imediata |
| Complexidade | Retorno do resultado (Returning Results), idempotência, DLQ |
| Ilusão de capacidade | A fila esconde subcapacidade até estourar |
O terceiro é o mais perigoso. Se a taxa média de chegada excede a de processamento, a fila não está nivelando — está acumulando. O sistema parece saudável enquanto entrega respostas cada vez mais antigas, até que retenção, memória ou disco acabem.
Por isso a métrica que importa não é o tamanho da fila, é a idade da mensagem mais antiga. Uma fila com 100 mil mensagens que esvazia em dois minutos está saudável; uma com 5 mil que só cresce, não.
E o padrão só se aplica quando a operação pode esperar. Para uma requisição síncrona cujo cliente precisa da resposta agora, a fila apenas transfere o problema — a saída ali é Throttling ou escalar.
Exemplo prático
Uma API de processamento de imagens: 100 requisições/s em média, com picos de 2.000/s em campanhas.
Sem fila, é preciso manter capacidade para 2.000/s o tempo todo — 20 vezes o necessário na maior parte do dia.
Com fila, mantêm-se workers para ~150/s. Durante o pico, a fila cresce até ~10 mil mensagens e esvazia nos minutos seguintes. A latência da última imagem do pico sobe para alguns minutos, e nenhuma requisição é rejeitada.
O alerta que fecha o desenho: idade da mensagem mais antiga > 5 minutos. É ele que distingue "estamos absorvendo um pico" de "não temos capacidade" — e a segunda situação exige escalar workers, não uma fila maior.
Relacionado
Parte de Messaging · roadmap.sh/system-design