Backpressure e filas limitadas: deixar o estágio mais lento ditar o ritmo

O que é

Backpressure é o controle de fluxo entre os estágios de um pipeline: o consumidor sinaliza quanto consegue aceitar, e o produtor espera ou reduz o ritmo. O Reactive Streams (citado) define seu objetivo como governar a troca de dados de um stream através de uma fronteira assíncrona, de modo que o lado receptor não seja forçado a armazenar em buffer quantidades arbitrárias de dados, o que permite limitar as filas entre threads; nas suas interfaces, o subscriber sinaliza a demanda solicitando elementos. No Node.js (citado), writable.write() retorna false assim que o buffer interno atinge highWaterMark, e o evento 'drain' indica quando a escrita pode ser retomada; stream.pipeline() faz essa ligação entre os estágios.

O livro Google SRE (citado) descreve a versão voltada ao atendimento de requisições: a maioria dos servidores com uma thread por requisição mantém uma fila na frente de um pool de threads; se a fila está cheia, o servidor rejeita as requisições. Filas longas aumentam a latência e o uso de memória, e, para um tráfego razoavelmente estável, o livro recomenda filas pequenas em relação ao pool de threads, para que o servidor rejeite cedo quando não consegue sustentar a taxa de entrada.

Por que importa

Todo buffer sem limite (uma lista em memória de jobs pendentes, um canal ilimitado, um servidor HTTP que aceita sem limite) esconde a sobrecarga até que o processo fique sem memória ou até que a latência ultrapasse o timeout de todos os clientes; nesse ponto os clientes tentam de novo e pioram a situação. Filas limitadas tornam a sobrecarga visível e a revelam cedo.

Como aplicar

• Limite todas as filas e escolha um de três comportamentos para quando estiverem cheias: bloquear o produtor (backpressure), rejeitar o item mais novo (shed) ou descartar o mais antigo (somente quando dados recentes substituem os antigos).
• Propague o sinal até a borda: uma requisição rejeitada vira um HTTP 503 ou 429 com Retry-After, e não uma espera silenciosa.
• Em código assíncrono, use canais limitados ou semáforos ao redor das chamadas a dependências mais lentas; em código com streams, use o helper de pipeline da plataforma em vez de handlers manuais de on('data').
• Dimensione as filas pela espera aceitável: o tamanho da fila dividido pela vazão é a latência adicional na saturação.
• Meça o tempo de espera na fila (idade do item mais antigo) e a contagem de rejeições; ambos são sinais de sobrecarga melhores que a CPU.

Armadilhas

Bloquear um produtor que mantém um lock ou uma conexão de banco de dados pode causar deadlock no sistema. Timeouts sem rejeição deixam o trabalho enfileirado para ser executado depois que o cliente já foi embora. Uma fila na frente de uma dependência que também tem fila multiplica a latência. As tentativas repetidas (retries) vindas de upstream devem ser contabilizadas como carga.