Define limits by tenant, operation, cost or dependency capacity.
Reliability & Delivery · Load Protection
Throttling
Measure consumption and delay, reject or degrade requests that exceed defined limits. Good throttling communicates limits clearly and protects both shared capacity and important workloads.
How can a system keep legitimate demand within the capacity and fairness limits of a shared resource?GateSift summary based on Microsoft Azure Architecture Center guidance. The wording, visualization, Azure mapping and analyzer context are original GateSift material.
Original GateSift visualization
How Throttling works
Requests are measured against capacity or fairness limits before they consume a constrained resource.
Incoming demand
Consumption limits
Allowed
Delayed / rejected
Allow, delay, queue or reject work when the configured limit is reached.
Return clear retry guidance and monitor whether limits protect the system without blocking valid traffic.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use throttling to protect constrained capacity or enforce fair consumption before excess demand turns into timeouts, queue growth or dependency failure.
- A backend, tenant, API or shared resource has a known sustainable capacity.
- Fairness requires per-caller, per-key or per-operation consumption limits.
- Rejecting or delaying excess demand is safer than allowing uncontrolled saturation.
- The real problem is a short burst that can be absorbed safely by a durable queue.
- One global limit would penalize unrelated customers or workloads with different capacity budgets.
- The client receives no retry guidance and will simply retry immediately, creating more pressure.
Wrong keyHigh impact
A limit keyed too broadly can let one tenant affect others; keyed too narrowly it may not protect the backend.
Client retry loopReview
Rejected callers can amplify load if retry timing is not communicated and respected.
Capacity driftReview
Static limits become unsafe or wasteful when backend capacity changes significantly.
- APIM rate-limit-by-key is useful when the gateway has the right caller or tenant key and owns admission control.
- For asynchronous workloads, queue-based load leveling can be more appropriate than rejecting demand outright.
- Monitor throttled requests alongside backend saturation so limits can be tuned from evidence rather than guesswork.
What this pattern helps you decide
Measure consumption and delay, reject or degrade requests that exceed defined limits. Good throttling communicates limits clearly and protects both shared capacity and important workloads.
What resource is the limit protecting and what is its measured sustainable capacity?
Is the throttling key aligned with tenant or workload fairness?
Do callers receive a clear signal for when and how to retry?
Where you may see it
- APIM rate-limit and quota policies
- Service Bus or Event Hubs producer pacing
- Application-level tenant and operation limits
How the analyzers can surface it
- APIM APIs without rate limiting or quota controls
- Shared integrations with no tenant or consumer isolation
- HTTP 429 handling and retry-after behavior
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Source guidance and attribution
This page links to Microsoft Azure Architecture Center for the source architecture guidance. GateSift summaries, diagrams, Azure examples and analyzer signals are original. No endorsement by Microsoft is implied.