Quando uma API, um webhook ou uma interface cria trabalho mais rápido do que o serviço downstream consegue concluir, a fila absorve o pico, mas não elimina o déficit de capacidade. Sem retorno de pressão, o backlog cresce até acabarem latência aceitável, memória, armazenamento ou paciência das pessoas. Backpressure torna esse descompasso visível e limitado.
Profundidade isolada é ambígua. Combine-a com ritmo de entrada e conclusão, idade da mensagem mais antiga, retries e saturação dos consumidores. Uma fila longa pode ser normal em lote; uma mensagem envelhecida num fluxo interativo pode ser incidente. Estime o tempo de drenagem considerando a capacidade excedente e novas chegadas, sem supor que a fila ficará parada.
| Fronteira | Mecanismo | Troca envolvida |
|---|---|---|
| Entrada HTTP | Rate limit, concorrência e resposta 429/503 com orientação de retry | Protege o serviço, mas exige retry responsável do cliente |
| Entrega do broker | Limite de prefetch/lote e acknowledgements explícitos | Limita trabalho em voo; muito baixo reduz vazão |
| Workers | Concorrência e tamanho de fila limitados | Memória previsível; excesso espera ou é rejeitado |
| Banco de dados | Pool de conexões, bulkhead e controle de admissão | Evita colapso, mas pode aumentar latência anterior |
| Navegador | Debounce, cancelar requisições obsoletas e limitar paralelismo | Reduz demanda duplicada, podendo atrasar a interface |
Uma fila em memória sem limite não é resiliência: transforma sobrecarga em crescimento de memória e falha posterior. Defina limites de fila e payload, expiração e o destino do excedente: rejeitar, agregar, persistir ou descartar. Sugestões de digitação podem ser descartadas; reconciliações financeiras, não.
Adicionar consumidores ajuda quando a dependência também tem capacidade. Se banco ou API parceira já estiver saturado, mais workers elevam contenção e retries. Limite concorrência na fronteira da dependência, use backoff exponencial com jitter e respeite orientações do provedor. Circuit breaker precisa de teste de recuperação e política segura de drenagem.
Em fluxos ordenados, particione por chave estável para uma mensagem problemática não bloquear todas as outras. Com entrega pelo menos uma vez, confirme após sucesso durável e torne efeitos idempotentes. Ajuste timeout de visibilidade ou acknowledgement à duração típica, com extensão controlada para tarefas longas.
Backpressure faz parte do contrato da API. Retorne status de sobrecarga claro, sinal Retry-After quando adequado e identificador de correlação. No processamento assíncrono, só confirme após persistir duravelmente e ofereça consulta de status ou callback. Não diga “aceito” para algo que existe somente na memória volátil.
Mostre juntos entrada e conclusão, percentis de idade, mensagens em voo, retries, volume de dead-letter, uso dos consumidores e saturação da dependência. Alerte por crescimento contínuo e tempo estimado para esvaziar, não por limiar de tamanho desconectado da carga. Durante a recuperação, indique se a fila está drenando e evite tempestade sincronizada de retries.
Relacionado: arquitetura com filas e limites de API como arquitetura de produto.
Backpressure é uma política de capacidade expressa em buffers limitados, concorrência controlada e respostas explícitas à sobrecarga. Meça entrada e conclusão, proteja a dependência mais lenta e decida o que adiar ou rejeitar antes que o sistema decida por você.