You can configure the Apigee Quota policy to enforce a dynamic and varying quota, on a per user basis. You can accomplish what you want.
There are different "types" of Quota in Apigee. Rolling Window, Calendar, Flexi, and "default". Let's suppose you want a limit of 2000/day, and you want the day to start at midnight. For that you can use the Calendar type, and you can specify a StartTime of midnight (for your local time). That means the counting interval starts at midnight, whether or not the user is making any requests. (There are other Quota types that begin the counting interval, upon receipt of the first request).
ok so the simple case is a static configuration: 2000 requests per day . This looks like the following:
<Quota name="Quota-1" type="calendar">
<StartTime>2021-02-18 10:30:00</StartTime>
<Interval>1</Interval>
<TimeUnit>day</TimeUnit>
<Allow count="2000"/>
</Quota>
And then you would attach that Quota policy in the request preflow of the proxy, it would look like this:
<ProxyEndpoint name='endpoint1'>
<Description>Proxy Endpoint 1</Description>
<HTTPProxyConnection>
<BasePath>/whatever</BasePath>
</HTTPProxyConnection>
<PreFlow name='PreFlow'>
<Request>
<Step>
<Name>Quota-1</Name>
</Step>
</Request>
<Response>
</Response>
</PreFlow>
...
But what you want is a varying allowance. For some people it will be 2000, for others it will be 3000, for others it will be unlimited. I suppose the determination whether a user should be given 2000, 3000, or unlimited will be externally determined - it is not encoded in the Apigee proxy itself, but is determined by some other logic that runs external to the proxy. Call it a microservice. The ratings microservice.
To make this happen you need to configure Apigee to call into the ratings microservice before it tries to enforce the quota. You might run the rater, every hour, or every day. But let's expose the computed ratings data via a service. Then, in the flow, you must use a ServiceCallout policy to retrieve the rating for the current user. But what is the current user? Maybe that is determined by the inbound JWT access token. So first you must verify the JWT, then make the call to the ratings service, then enforce the quota. The flow now look slike this:
<ProxyEndpoint name='endpoint1'>
<Description>Proxy Endpoint 1</Description>
<HTTPProxyConnection>
<BasePath>/whatever</BasePath>
</HTTPProxyConnection>
<PreFlow name='PreFlow'>
<Request>
<Step>
<!-- verify the user and get the inbound token -->
<Name>VerifyJWT-1</Name>
</Step>
<Step>
<!-- call to the ratings service -->
<Name>SC-Ratings-Service</Name>
</Step>
<Step>
<!-- enforce the dynamic quota -->
<Name>Quota-1</Name>
</Step>
</Request>
<Response>
</Response>
</PreFlow>
...
Let's suppose the response from the ratings service is a JSON payload. Depending on the response from the ratings service your quota policy will do different things. So we need a few more changes. We need to extract the "tier" of user from the response, and also the allowed # of calls. So we can use an ExtractVariables policy to do that. Then we have context variables that hold the information we seek. Then, enforce the quota IF and only IF, the user is not in the unlimited tier. So we surround the quota with a Condition. And also, if we do actually enforce the quota, apply the rate limit that the ratings service gave us. The quota policy now looks like this:
<Quota name="Quota-1" type="calendar">
<StartTime>2021-02-18 10:30:00</StartTime>
<Interval>1</Interval>
<TimeUnit>day</TimeUnit>
<Allow countRef='variable_containing_count'/>
</Quota>
and in the flow it is wrapped like this :
<ProxyEndpoint name='endpoint1'>
<Description>Proxy Endpoint 1</Description>
<HTTPProxyConnection>
<BasePath>/whatever</BasePath>
</HTTPProxyConnection>
<PreFlow name='PreFlow'>
<Request>
<Step>
<!-- verify the inbound token, and get the inbound user -->
<Name>VerifyJWT-1</Name>
</Step>
<Step>
<!-- call to the ratings service, to get the rate limit per user -->
<Name>SC-Ratings-Service</Name>
</Step>
<Step>
<!-- extract the response from the ratings service, into variables -->
<Name>EV-Ratings-Data</Name>
</Step>
<Step>
<!-- conditionally apply the dynamic quota using the extracted variables -->
<Condition>user_tier != "unlimited"</Condition>
<Name>Quota-1</Name>
</Step>
</Request>
<Response>
</Response>
</PreFlow>
...
That's the basic structure. Now of course, you might not want to call the ratings service for every inbound call. So maybe you wrap the ServiceCallout with a cache. Basically insert the response into a cache, and check the cache before the ServiceCallout.
And maybe the inbound token is not a JWT; that's ok, Apigee can verify tokens of a different type. The main thing you need there is a way to extract a user identifier from the inbound credential (token) for the call.
Does this make sense? You could do this yourself, though it may take a bit of iteration to sort it out.
LinkedIn
Twitter
