I think, Rolling window helps you smoothen the load on target server instead of a fixed window of time where target server receives much traffic in defined fixed interval. Just using rolling window on universal quota doesn’t make much difference to target server. Rolling window in combination with dynamic counters using flow variables does make a difference related to load on target server at any point of time. Am i right ?
Any other advantages / disadvantages that you have seen with rolling window type in Quota Policy compared to fixed window ?
Solved! Go to Solution.
The differences are summarized here, in the doc.
A rolling window is ... just what it says... basically it enforces a limit of requests in any 1 unit of time. 1 hour, 1 week, 1 month. The unit of time is always rolling. So that if I make a request on Thursday at 13:00, and the quota policy is set with a rolling window quota of 1-day interval, then Apigee Edge calculates the number of requests I have made in the last 24 hours - since Wednesday at 13:00 - and enforces the quota limit based on that.
Contrast to the default quota, in which the counter resets every day at midnight. Using the same example from above, if I make a request on Thursday at 13:00, then the quota policy will count requests that I have made since the prior midnight (Thursday 00:00).
Which quota is better depends on your needs, and the way you've set up your contractual Terms and Conditions.
Using a rolling window on universal quota - I guess you mean "no identifier", meaning one large quota bucket (or counter) of requests for all clients - will mean that the target server will receive at most N requests in any given time period. Using the default quota counter type, this guarantee won't be true.
Consider this scenario. You have an API that receives requests over the course of 2 days. The quota is set for a daily limit. In the first case you use the "default" counter, in which the counters reset at midnight. Suppose you set the quota to 1000 requests per day.
Now consider a usage profile in which 1000 requests are made, but all between 23:30 and 00:00. And then an additional 1000 requests arrive, between 00:00 and 0:30. All of these requests will be allowed under the default quota counter reset. If another request, N=2001, arrives at 00:31, then the quota will reject it because there have been 1000 requests since midnight. And any further request will be rejected until midnight. So the default quota allows 2000 requests within 1 hour! But never more than 1000 requests, in any 24 hour period starting at 00:00.
Now consider a rolling window. As above, the quota is configured to allow 1000 requests per day. The first 1000 requests, between 23:30 and 00:00 will be allowed, but the request N=1001 arriving at 00:01 will be rejected by the rolling window quota policy, because there have been more than 1000 requests in the past 24 hours. In fact all requests until the next 23:30 will be rejected with the rolling window. The rolling window will not allow more than 1000 requests in ANY 24-hour period.
Will this difference in behavior have any effect on backend systems? I don't know - that depends on what the backend system looks like. Surely the rolling window is more restrictive.
I don't know just what you mean by "Rolling window in combination with dynamic counters using flow variables."