Rate Limiting Across a Shared Gateway
A retail company exposes three API products on one Boomi API Gateway: Orders (internal mobile app, 400 req/min peak), Partner Shipping (12 external logistics partners, 90 req/min combined), and Public Catalog (anonymous, bursts to 1,500 req/min during flash sales). All three currently share a single gateway-level rate limit of 2,000 req/min. During a flash sale, Catalog traffic saturated the limit and Orders requests were rejected with 429s, delaying order confirmation for 6 minutes. Partners also report intermittent throttling despite low volume. The platform team proposes raising the shared limit to 5,000 req/min. The security team wants per-consumer keys; the partner team wants per-partner quotas. Budget allows one gateway cluster with no additional nodes this quarter.
1. Evaluate the proposal to raise the shared gateway limit to 5,000 req/min. What is the failure mode, and what should be done instead given a single cluster with no new nodes?
Read the worked answer
Raising a shared limit does not fix the problem; it only moves the collision point. The failure mode is noisy-neighbor contention: anonymous Catalog bursts consume a pooled budget, and Orders and Partner traffic compete for the same tokens. At 5,000 req/min a larger flash sale would still evict Orders, and the 429s would simply arrive later. The correct design is per-consumer scoping: apply rate limits at the API product/plan level (and per application key for partners) rather than one gateway-wide ceiling. Orders gets a dedicated allowance sized to its 400 req/min peak plus headroom; Partner Shipping gets a per-partner quota (for example 8 req/min each) that aggregates to roughly the 90 req/min combined figure; Public Catalog gets its own burst allowance with a lower sustained rate. Because the cluster cannot scale horizontally, the team must also protect the shared capacity: set a global safety ceiling above the sum of plan limits only if measured node capacity supports it, and add caching or response offload for Catalog. This isolates blast radius without new hardware.
2. Partners report throttling despite low volume. Using the setup, give two plausible causes and how you would diagnose each.
Read the worked answer
Cause 1 - pooled partner budget consumed by one partner. With 12 partners sharing the product allowance, one partner retrying aggressively can exhaust the shared bucket, so compliant partners see 429s at low personal volume. Diagnose by inspecting per-application (per-key) request counts and 429 rates in gateway analytics over the same window; if one key dominates while others are starved, the quota is mis-scoped. Fix: per-partner quotas.
Cause 2 - collision with Catalog bursts on the shared gateway limit. Even at low partner volume, anonymous Catalog spikes can consume the shared 2,000 req/min pool, producing partner 429s that correlate with sale windows rather than partner traffic. Diagnose by time-aligning partner 429 timestamps with Catalog request-rate graphs; a strong correlation with Catalog peaks and no correlation with partner volume confirms contention. Fix: separate plan-level limits so Catalog cannot draw from the partner budget. In both cases, confirm whether limits are enforced per key or per gateway before changing thresholds - otherwise you may raise a limit that is not the actual constraint.