Skip to content

PATTERN Cited by 1 source

Per-tenant rate limiting

Pattern

Apply a distributed rate limiter at the delivery leaf, scoped at two levels:

  1. Per-app-and-environment — caps any single subscription from consuming more than its share.
  2. Per-tenant — caps any single tenant's collective subscriptions from doing the same.

Both buckets must allow capacity for delivery to proceed. The rate limiter is system protection, not per-tenant policy. Enforcement is cluster-wide (shared service across all delivery pods) so limits hold consistently regardless of which pod picks up the next message.

What it catches

  • A webhook recipient suddenly accepting deliveries far slower than normal
  • An unexpected spike in subscriptions for a high-volume event type
  • An app subscribing more broadly than its capacity to receive

Without rate limits, any of these can pull more outbound capacity than the platform has and degrade delivery for everyone else sharing the same path.

Behaviour on limit hit

When capacity is exhausted, the delivery is deferred, not dropped, and re-evaluated as the bucket refills. The deferral policy is chosen per pipeline — different event surfaces need different handling (Source: sources/2026-07-29-atlassian-inside-the-events-rail).

Distinction from per-recipient concurrency limiting

Rate limiting catches volume — too many requests. It does not catch latency — a recipient receiving requests at normal rate but taking 10 seconds per response never trips a rate limit. That's the domain of patterns/per-recipient-concurrency-limiting.

Seen in

Last updated · 602 distilled / 1,824 read