Back
Pressure

SECTION 01

The problem

Every system has a real processing capacity. The API may receive many calls, but the database, workers, CPU, memory, or an external API may process work at a lower rate.

When the arrival rate stays higher than the processing rate long enough, the work does not disappear. It accumulates somewhere.

Clients
   ↓
1000 req/s
   ↓
API
   ↓
Queue
   ↓
Workers process 500 req/s

In this scenario, 1000 requests enter per second and 500 leave. The difference becomes backlog. If nothing limits that accumulation, the queue grows, latency rises, memory usage increases, and the system can crash.

SECTION 02

Without back pressure

Without back pressure, the application accepts work as if every resource were infinite. That is the mistake: an unbounded queue looks comfortable at first, but eventually becomes consumed memory and hidden latency.

1000 in
500 out

+500
+500
+500
+500

The system appears to be working because it still accepts new requests. But each new request increases the wait time for work that is already in the queue.

SECTION 03

Bounded queue

The first step in applying back pressure is accepting that the queue needs a maximum size. That limit defines how much waiting you accept before saying: not now.

A simple way to think about queue size is to start from the maximum acceptable latency:

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

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

Example: each operation takes 100 ms and there are 10 workers.

100 ms / 10 workers = 10 ms per queued item

maximum accepted latency = 1000 ms

1000 ms / 10 ms = 100 items

In that case, a queue around 100 items represents roughly 1 second of waiting. Above that, the system needs to block, slow down, or reject.

SECTION 04

How pressure moves back

Back pressure is not just having a queue. The point is what happens when the limit is reached.

Slow worker
     ↑
Queue full
     ↑
API stops accepting more work
     ↑
Client receives retry, 429 or 503

In an HTTP API, two common responses are:

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

HTTP/1.1 503 Service Unavailable
Retry-After: 2

The system is saying: I am full right now; try again later. That is better than accepting everything and making every user fail together.

SECTION 05

Applying it to a match system

In a match system, back pressure makes sense anywhere many players can generate events at the same time while some resource has limited capacity.

Imagine a match with 20 slots and 2000 people trying to join almost simultaneously. The decision to reserve a slot should not depend on a regular queue. It needs to be atomic in the database.

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

This is the consistency path: confirm the slot now, with a database transaction. The queue fits better for what can happen later: notifications, ranking, analytics, email, push, or content generation.

That separates two worlds:

• Consistency path: reserve a slot, confirm attendance, change critical match state.
• Async path: notify players, update ranking, emit analytics, process slow tasks.

If 5000 notifications need to be sent after a cancellation, workers can send 50 per second. If the external provider becomes slow, the queue grows up to the limit and the API stops pushing infinite work.

SECTION 06

Protection layers

Back pressure usually appears as a set of limits. Each limit protects the next resource.

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

Rate limiting controls how much a client can send. Concurrency limiting controls how many operations run at the same time. A connection pool limits access to resources such as the database. A bounded queue limits how much work can wait.

Back pressure is the resulting behavior when those limits make the previous component slow down, wait, or receive an explicit rejection.

SECTION 07

Core idea

The core idea is simple:

Back pressure prevents
a system that is too fast at the input
from destroying a slower component at the output.

In this kind of system, that means controlling how much work enters each component when many players do something at the same time.

Instead of throwing 10000 operations at the database or a worker, the system accepts only what it can handle well. The excess waits briefly, slows down, or receives a clear response to try again.