Overview
Quota and SpikeArrest solve different problems and behave differently. SpikeArrest smooths instantaneous rate at the message processor level; Quota counts against a distributed counter over a window. Configuring one where you needed the other produces exactly the symptom this customer had.
Challenge
Partners were receiving throttling responses well below their contracted call volume, while a genuine traffic burst from a single partner still reached the backend and degraded it. SpikeArrest was set at a rate that assumed a single message processor, and the Quota policy was not configured as distributed or synchronous, so counts diverged across processors.
Environment
Apigee X fronting reservation and inventory backends, with partner-tier quotas defined in API products.
Approach
AceMQ mapped the intended commercial rate limits onto the correct policy for each behavior — burst smoothing versus contractual volume — and corrected the counter distribution settings. We then validated with a load profile that reproduced both a steady partner load and a realistic burst.
Solution
- Separated burst smoothing (SpikeArrest) from contractual volume enforcement (Quota) explicitly
- Enabled distributed and synchronous counting so quota counts do not diverge across message processors
- Aligned quota identifiers with API product and developer app rather than proxy-level defaults
- Corrected SpikeArrest rates to account for the number of message processors actually serving traffic
- Load-tested with both sustained partner traffic and realistic burst profiles before rollout
Outcome
Legitimate partner traffic stopped being rejected below contracted volume, and burst traffic is now smoothed at the gateway instead of reaching the backend intact.
Technologies
Apigee
Redis
Kubernetes
Kong
Docker
NGINX
PostgreSQL
