Back
Pressure

SECAO 01

O problema

Todo sistema tem uma capacidade real de processamento. A API pode receber muitas chamadas, mas o banco, os workers, a CPU, a memoria ou uma API externa podem processar em um ritmo menor.

Quando a taxa de chegada fica maior que a taxa de processamento por tempo suficiente, o trabalho nao desaparece. Ele acumula em algum lugar.

Clientes
   ↓
1000 req/s
   ↓
API
   ↓
Fila
   ↓
Workers processam 500 req/s

Nesse cenario, entram 1000 requisicoes por segundo e saem 500. A diferenca vira backlog. Se nada limitar essa acumulacao, a fila cresce, a latencia sobe, a memoria aumenta e o sistema pode cair.

SECAO 02

Sem back pressure

Sem back pressure, a aplicacao aceita trabalho como se todos os recursos fossem infinitos. Esse e o erro: fila infinita parece conforto no comeco, mas vira memoria consumida e latencia escondida.

1000 entram
500 saem

+500
+500
+500
+500

O sistema parece estar funcionando porque ainda aceita novas requisicoes. Mas cada nova entrada aumenta o tempo de espera de quem ja esta na fila.

SECAO 03

Fila limitada

O primeiro passo para aplicar back pressure e assumir que a fila precisa ter tamanho maximo. Esse limite define quanta espera voce aceita antes de dizer: agora nao.

Uma forma simples de pensar no tamanho da fila e partir da latencia maxima aceitavel:

max latency = (transaction time / threads) × queue length

queue length = max latency / (transaction time / threads)

Exemplo: cada operacao leva 100 ms e existem 10 workers.

100 ms / 10 workers = 10 ms por item na fila

latencia maxima aceita = 1000 ms

1000 ms / 10 ms = 100 itens

Nesse caso, uma fila perto de 100 itens representa aproximadamente 1 segundo de espera. Acima disso, voce precisa bloquear, desacelerar ou rejeitar.

SECAO 04

Como a pressao volta

Back pressure nao e apenas ter uma fila. O ponto e o que acontece quando o limite e atingido.

Worker lento
     ↑
Fila cheia
     ↑
API para de aceitar mais trabalho
     ↑
Cliente recebe retry, 429 ou 503

Em uma API HTTP, duas respostas comuns sao:

HTTP/1.1 429 Too Many Requests
Retry-After: 1

HTTP/1.1 503 Service Unavailable
Retry-After: 2

O sistema esta dizendo: estou cheio agora; tente de novo depois. Isso e melhor do que aceitar tudo e derrubar todos os usuarios juntos.

SECAO 05

Aplicando em um sistema de partidas

Em um sistema de partidas, back pressure faria sentido nos pontos em que muitos jogadores geram eventos ao mesmo tempo, mas algum recurso tem capacidade limitada.

Imagine uma partida com 20 vagas e 2000 pessoas tentando entrar quase simultaneamente. A decisao de reservar vaga nao deve depender de uma fila comum. Ela precisa ser atomica no banco.

UPDATE match
SET available_slots = available_slots - 1
WHERE id = ?
  AND available_slots > 0;

Esse e o caminho de consistencia: confirmar vaga agora, com transacao no banco. A fila entra melhor no que pode acontecer depois: notificacao, ranking, analytics, email, push ou geracao de conteudo.

Assim o sistema separa dois mundos:

• Consistency path: reservar vaga, confirmar presenca, alterar estado critico da partida.
• Async path: notificar jogadores, atualizar ranking, emitir analytics, processar tarefas demoradas.

Se 5000 notificacoes precisarem sair apos um cancelamento, os workers podem enviar 50 por segundo. Se o provedor externo ficar lento, a fila cresce ate o limite e a API para de empurrar trabalho infinito.

SECAO 06

Camadas de protecao

Back pressure normalmente aparece como um conjunto de limites. Cada limite protege o recurso seguinte.

Internet
   ↓
Rate Limit
   ↓
Concurrency Limit
   ↓
Connection Pool
   ↓
Bounded Queue
   ↓
Workers
   ↓
PostgreSQL / APIs externas

Rate limiting controla quanto um cliente pode enviar. Concurrency limiting controla quantas operacoes rodam ao mesmo tempo. Connection pool limita o acesso a recursos como banco. Bounded queue limita quanto trabalho pode esperar.

Back pressure e o comportamento resultante quando esses limites fazem quem esta antes desacelerar, esperar ou receber uma rejeicao explicita.

SECAO 07

Ideia central

A ideia central e simples:

Back pressure serve para impedir que
um sistema rapido demais na entrada
destrua um componente mais lento na saida.

Nesse tipo de sistema, isso significa controlar quanto trabalho entra em cada componente quando muitos jogadores fazem algo ao mesmo tempo.

Em vez de jogar 10000 operacoes em cima do banco ou de um worker, o sistema aceita ate onde consegue operar bem. O excesso espera pouco, desacelera ou recebe uma resposta clara para tentar novamente.