Skip to content

PATTERN Cited by 1 source

Per-recipient concurrency limiting

Pattern

Cap how many deliveries to a given recipient can be in-flight at once, tracked in a shared cluster-wide counter so the limit holds regardless of which pod picks up the next message. When a recipient slows down, its in-flight deliveries pile up against its own cap, and further deliveries are deferred rather than dispatched.

What it catches

Per-tenant rate limiting catches volume (too many requests). Concurrency limiting catches latency: a recipient receiving requests at a perfectly normal rate but taking 10 seconds to answer each one never trips a rate limit. Left unchecked, that recipient can quietly tie up shared delivery capacity one slow response at a time.

Mechanism

  • Limit is scoped per recipient, applied selectively where a concurrency budget is configured.
  • Each reservation carries a short expiry — a pod crash or dropped release doesn't leave capacity permanently stuck.
  • When healthy: deliveries flow untouched. When slow: in-flight deliveries hit the cap → further deliveries deferred.

Relationship to blast radius

This is the mechanism that makes "contained blast radius" work in delivery systems. A slow recipient's impact is bounded to its own concurrency cap — it cannot starve the rest of the platform (Source: sources/2026-07-29-atlassian-inside-the-events-rail).

Seen in

Last updated · 602 distilled / 1,824 read