What are the Advantages / Disadvantages of Rolling window in Quota Policy compared to Fixed window of interval ?

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 Solved
1 3 2,081
1 ACCEPTED 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."

View solution in original post

3 REPLIES 3

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."

@Dino , Thank you for the detailed answer. It's helpful. Regarding, "Rolling window in combination with dynamic counters using flow variables." I mean rolling window with identifier.

Ahhh, I see. The Quota with an identifier won't necessarily protect your backend system, because the number of client systems (and client ids) is theoretically unbounded. Suppose your quota is 100/day. If you have 100 clients, then that's a maximum of 10,000 requests per day that reach the backend (with the understanding about counter resets that we just talked about up there ^^). But you might have 200 clients, or 1000 clients, in which case it's 20k requests or 100k requests.

By the way I always thought the client_id was the wrong identifier to use, in any case, in a Quota. If you have rotating credentials, the client id may change! So it is probably more correct to use the developer app id. But the key rotation may happen only rarely - like every 90 days or 180 days or whatever. So maybe it is basically equivalent to client_id, with a small window of exposure when the client_id lifetimes overlap. This isn't relevant to your question, but I thought I'd put it out there.