Quotas and rate limiting are integral protection mechanisms for online services. As a refresher, quotas define the total number of times a specific action can be taken. Depending on the context, quotas can be lifetime or within a defined interval. Rate limits define the speed at which an action can be taken, like the number of data queries a client can make per second.
Such limits exist to protect organizations at every level of the stack from abuse and overspending, and each level grants you different degrees of granularity. At the cloud host level, limits can be imposed on Squid as a whole. At the Squid level, we can impose limits on individual applications based on the allotments defined for your chosen tier.
But therein lies the problem - your application as a whole has limits, but what if you wanted more granularity?
Some use cases
A user abuses your service and leaves no available quota for everyone else. What if you could configure to enforce limits per user, or even by IP address?
You’ve connected your database to Squid but you know the database can’t handle too much load, or that your database provider has their own billing structure. What if you could make sure you don’t exceed these external limitations?
Introducing configurable limits for your backend functions!
Defining your limits
You can decorate your Squid backend functions with flexible and configurable limits using the @limits() syntax. The configuration is powerful, allowing different limits based on the user account, the user’s IP, or as a global limit.
These limits are stackable, such as having a global rate limit of 10 queries per second (QPS), while also imposing a 7 QPS limit on any individual user:
@limits({
rateLimit: [
{ value: 7, scope: 'user' },
{ value: 10, scope: 'global' },
],
})
@executable()
doUserAction(): boolean { ... }
This type of limit helps prevent any individual user from disproportionately impacting your usage, so you don’t have to worry about unexpectedly running out of resources or receiving a surprise bill.
Quotas can be stacked as well, and they can be defined alongside rate limits. Here you can see quota limits being defined per user with different renewal periods (monthly and annually).
@limits({
rateLimit: [
{ value: 5, scope: 'user' },
{ value: 10, scope: 'ip' }
],
quotaLimit: [
{ value: 7, scope: 'user', renewPeriod: 'monthly' },
{ value: 20, scope: 'user', renewPeriod: 'annually' }
]
})
@executable()
doUserAction(): boolean { ... }
Any combination of limits is possible, so configure to your heart’s content!
Rate limits and quotas provide you the peace of mind to know that your apps will perform properly without the risk of usage surprises, so why not set your limits today? Learn more about specific limit behaviors in our docs and check out our Discord if you have any questions or comments!