Multiple Identifiers in Quota policy

acharyadr
Participant II

Is it possible to have multiple identifers in Quota policy? For example, if i want to limit the quota based on client id and user id, would that be possible

1 2 508
2 REPLIES 2

@DAcharya, You could try defining a custom variable to concatenate the clientid and user id before the quota policy step and add a reference to the custom variable in the identifier element. I haven't tried it though.

The identifier is a single item.

However, you could use a preceding AssignMessage policy to create an appropriate identifier, composed of multiple data items.

<AssignMessage name='AM-QuotaIdentifier'>
  <AssignVariable>
    <Name>quota_identifier</Name> 
    <Template>{client_id}-{user_id}</Template>
  </AssignVariable>
</AssignMessage>

And then specify that as the identifier in the quota policy:

<Quota name='Q-1' type='flexi'>
    <Identifier ref='quota_identifier' />
    <Interval>1</Interval>
    <TimeUnit>minute</TimeUnit>
    <Allow count='300'/>
</Quota>

This would have the effect of enforcing the quota on the combination of client id and user id. What it means is that if the user were somehow authenticated with multiple clients - let's say v5 of the Android app and v6 of the iOS app - then the quotas would apply independently to those distinct combinations.

But are you sure?

Sometimes what people want is not a composite quota key, but rather, multiple distinct Quotas. For example you could chain Q-1 policy that limits on client_id, and then a second Quota policy, Q-2, which limits on user_id. This is entirely different semantics, do you see? This means ALL of the users running with the client identified by client_id, will be subject to the same quota limit. Eg, requests on behalf of every user employing v5 of the Android app would be counted in the same quota bucket. This means that if there is one very busy user using that Android app, it could cause request starvation for a whole bunch of other users of the Android app, but not for users of the iOS app. And then Separately, enforce another quota that on each user id. This kind of approach is good when you want a failsafe... as when you want to protect against a possible code bug in the client that would cause a flood of requests, but you also want normal limits on user traffic.

Which thing you want, depends on the behavior you desire. It's generally not a composite quota identifier that you want, and ... often people DO want multiple Quota policies in series.

LMK if questions.