Backpressure

Overview

Backpressure is a flow-control mechanism that prevents producers from overwhelming consumers, queues, databases, or downstream APIs when work arrives faster than it can be processed. The Backpressure implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

The principal risks include memory exhaustion, unbounded queues, excessive latency, dropped critical events, head-of-line blocking, hidden overload, and cascading failure across integrations. Backpressure regulates demand or admission; rate limiting usually enforces an external quota or policy at a request boundary.

A production implementation should bound queues, expose demand, slow or reject producers, prioritize critical payment events, shed nonessential load, isolate tenants, and define recovery behavior when capacity returns. Operational review of Backpressure should separate successful recovery from repeated attempts that only increase latency or load.

Useful measures include queue depth, oldest-message age, consumer lag, rejected work, processing latency, saturation, and time spent in degraded flow-control modes. Backpressure is closely connected to Rate Limiting, Message Queue, and Circuit Breaker. Configuration changes to Backpressure should be versioned and tested under burst, timeout, dependency failure, and restart conditions.

Metrics for Backpressure should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency. A Backpressure decision should use documented method semantics and provider error classes rather than message text alone.

Manual intervention for Backpressure should begin only after automated status checks cannot determine a safe final outcome. The Backpressure policy should define which failures are retryable, how long the decision remains valid, and how duplicate effects are prevented.