Throttling the wrong traffic while the real bursts get through
Redis
Kubernetes
KongLegitimate partner traffic stopped being rejected below contracted volume, and burst traffic is now smoothed at the gateway instead of reaching the backend intact.
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
- 1Separated burst smoothing (SpikeArrest) from contractual volume enforcement (Quota) explicitly
- 2Enabled distributed and synchronous counting so quota counts do not diverge across message processors
- 3Aligned quota identifiers with API product and developer app rather than proxy-level defaults
- 4Corrected SpikeArrest rates to account for the number of message processors actually serving traffic
- 5Load-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
RedisKubernetesKongRelated Use Cases
Apigee Proxy Latency and Policy Chain Support
Debugging proxy-level latency and policy execution problems in Apigee that sit outside what the platform vendor's support will investigate.
Apigee Proxy Estate and Shared Flow Redesign Assessment
Assessing a sprawling Apigee proxy estate and designing a shared flow architecture that removes duplicated policy logic across hundreds of proxies.
Facing a Apigee Production Issue?
AceMQ's senior Apigee engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.