Backpressure is a product decision
Every service that accepts work faster than it can finish it eventually needs a policy. The policy is usually written in code by accident: an unbounded channel here, a retry loop there, a database connection pool that waits forever. It looks like resilience. It behaves like a memory leak with extra steps.
Backpressure is often described as a technical mechanism: bounded queues, credits, 429 responses. Those are the instruments. The decision underneath is a product one. When the system is saturated, who waits, who gets a clear rejection, and who silently loses their request?
Three honest options
A bounded queue with a fast rejection tells the caller the truth. A bounded queue with a long timeout tells the caller a comfortable lie. An unbounded queue tells nobody anything until the process dies.
If you cannot describe what happens at 3x normal load in one sentence, the system does not have a load policy. It has a hope.
The useful exercise is to pick a latency budget and work backwards. If a request may wait two seconds, how many can be in flight? If the answer is smaller than the arrival rate, rejection is not a failure mode. It is the design.
This is also why generic dashboards are not enough. Queue depth is a symptom; age of the oldest item is the promise. Watch the promise.