Backpressure 🌊 — Handling More Work Than You Can Process

Backpressure is a mechanism used when a producer is generating work faster than a consumer can process it. Instead of allowing unlimited requests to accumulate, the system controls the incoming flow.

flowchart LR
    P["Fast Producer"] --> BP["Backpressure"]
    BP --> Q["Controlled Queue"]
    Q --> C["Consumer"]

1. Why Do We Need Backpressure?

Suppose a producer generates 10,000 messages per second, but the consumer can process only 2,000 messages per second.

flowchart LR
    P["Producer
10000/sec"] --> Q["Queue"]
    Q --> C["Consumer
2000/sec"]

    Q --> X["Queue Keeps Growing"]

If this continues, memory, queue storage, connections, or other resources can eventually be exhausted.

2. Backpressure Controls the Producer

The consumer can signal that it cannot accept more work. The producer then slows down, waits, or stops sending temporarily.

sequenceDiagram
    participant P as Producer
    participant C as Consumer

    P->>C: Send Work
    C-->>P: Processed

    P->>C: Send Work
    C-->>P: Slow Down

    P->>P: Reduce Production Rate

    P->>C: Send Work
    C-->>P: Processed

3. Backpressure with a Queue

A queue can absorb short traffic spikes, but it has finite capacity.

flowchart LR
    P["Producer"] --> Q["Message Queue"]
    Q --> W["Workers"]
    W --> C["Consumer"]

    Q -->|"Queue Full"| BP["Backpressure"]
    BP --> P

When the queue approaches its capacity, the producer may need to slow down, wait, or reject additional work.

4. Backpressure Strategies

• Slow Down — reduce the producer's sending rate.
• Buffer — temporarily store work in memory or a queue.
• Block — make the producer wait until capacity is available.
• Drop — discard work when it cannot be processed.
• Reject — explicitly reject new requests.

5. Backpressure vs Throttling

6. Backpressure in Distributed Systems

flowchart LR
    C["Clients"] --> G["API Gateway"]
    G --> Q["Queue"]
    Q --> W["Workers"]
    W --> DB["Database"]

    DB -->|"Slow / Limited Capacity"| W
    W -->|"Reduce Consumption"| Q
    Q -->|"Control Producers"| G

This prevents a slow downstream component from being overwhelmed by an unlimited amount of incoming work.

7. Real-World Example

Imagine an order-processing system receiving 20,000 orders per second, while workers can process only 5,000 per second.

flowchart LR
    O["Orders
20000/sec"] --> Q["Order Queue"]
    Q --> W["Workers
5000/sec"]

    Q --> BP["Backpressure"]

    BP --> O

The queue can absorb temporary bursts. If the backlog becomes too large, the system must slow or reject additional work rather than allowing the queue to grow without limit.

8. Backpressure with Other Resilience Patterns

flowchart LR
    C["Client"] --> RL["Rate Limiting"]
    RL --> T["Throttling"]
    T --> Q["Queue"]
    Q --> B["Bulkhead"]
    B --> TO["Timeout"]
    TO --> CB["Circuit Breaker"]
    CB --> S["Downstream Service"]

These patterns solve different problems but can work together to protect a distributed system from overload and dependency failures.

Important Interview Questions

• What is backpressure?
• Why is backpressure needed?
• What happens when a producer is faster than a consumer?
• How can a queue help with backpressure?
• What happens when the queue becomes full?
• Backpressure vs throttling?
• How would you handle 20,000 requests/sec when the backend processes only 5,000/sec?
• What are the possible backpressure strategies?

Key Takeaways

• Backpressure handles producer-consumer speed mismatch.
• The consumer's capacity influences how much work the producer should send.
• Queues can absorb temporary bursts but are not unlimited.
• The system may slow, block, drop, or reject work when capacity is exhausted.
• Backpressure is especially important in streaming, messaging, and asynchronous systems.

Conclusion

For interviews, remember: Producer Too Fast → Detect Capacity → Slow / Buffer / Reject → Protect Consumer.