Skip to content

CONCEPT Cited by 1 source

Multi-tenant fairness

Definition

Multi-tenant fairness is the property that a shared platform delivers predictable service to every tenant regardless of other tenants' behaviour — bulk operations, traffic bursts, or slow consumers in one tenant must not degrade service for others. Unlike single-tenant systems where resource contention is self-inflicted, multi-tenant systems must explicitly engineer isolation because fairness "never happens by accident" at scale.

Why it matters

In multi-tenant event delivery, storage, or compute platforms, three failure modes dominate without explicit fairness controls:

  1. Noisy-neighbor volume — one tenant's bulk operation (CSV import, security policy sweep) produces more traffic in a minute than it normally produces in a week, starving other tenants of capacity.
  2. Slow-responder contagion — a single slow downstream ties up shared delivery resources, creating head-of-line blocking for unrelated tenants.
  3. Subscription explosion — a broadly-scoped subscription consuming more events than the platform can sustainably deliver to it.

Layered fairness (Atlassian model)

Atlassian's Events Rail demonstrates the principle that multi-tenant fairness is layered, not centralized — no single mechanism is sufficient. Their four-layer model:

Layer Catches Mechanism
Negative-lookup cache Evaluation cost (miss-heavy lookups) Short-TTL cache of "no subscriptions"
Queue isolation Head-of-line blocking Per-pipeline separate queues + worker fleets
Per-tenant rate limiting Capacity exhaustion Distributed rate limiter (per-app-env + per-tenant)
Per-recipient concurrency limiting Slow-but-not-noisy recipients Cap on in-flight deliveries per recipient

Each layer catches a kind of pressure the layer above doesn't. The ordering matters: cheaper checks run first (Source: sources/2026-07-29-atlassian-inside-the-events-rail).

Design principles

  • Defer, don't drop. A silently dropped event is worse than a delayed one. When limits are hit, defer and re-evaluate rather than discard.
  • Scope limits narrowly. Per-app-and-environment and per-tenant buckets, not just global limits.
  • Cluster-wide enforcement. Limits must hold across all pods, requiring shared state (distributed rate-limiter service, cluster-wide counters).
  • Each surface declares its own policy. Different event surfaces need different timeout budgets, retry policies, and failure semantics.

Seen in

Last updated · 602 distilled / 1,824 read