Keep your API fast—even at peak

Northstar and Orchid are distinct organizations using one service. Follow Northstar’s circular N token and Orchid’s square O token; their identities remain readable without relying on color.

The two customer labels define which organization each request belongs to. The drawn work area is shared; identifying tenants does not automatically create separate servers, memory, or reserved execution slots.

Orchid’s tokens occupy the shared work area in this illustrative congested state. The number of drawn tokens is schematic, not a traffic rate, limit configuration, or measured processing capacity.

The same shared work area is occupied by Orchid’s activity while Maya’s Northstar request waits. The customer harmed by this congestion is not necessarily the customer producing the excess demand.

The congestion can come from a mistake in an integration rather than an intentional attack. The protection goal is to enforce intended use and preserve service for other tenants, not to infer the customer’s motives.

This is the desired protected alternative. Orchid’s excess is refused, while permitted Orchid work and Maya’s reasonable request can enter the shared work area. The request tokens do not specify a production quota or guarantee reserved capacity.

This contrasting policy rejects both tenants. It avoids adding this work but misses the noisy-neighbor goal: allowing reasonable use while containing the organization producing the excess.

Attach the tenant identity from trusted application context. A caller-provided name alone is not a trustworthy boundary; the admission decision must account against the correct organization before expensive work begins.

Return to the selective policy: refuse the excess rather than treating every customer as the problem. This protects useful service for people like Maya; it does not promise isolation from every possible shared-resource failure.