What is rate limit?

A rate limit is a security tool used to prevent excessive usage of a service to allow others relying on the service to continue utilising it with minimal impact or interruptions. It also helps to reduce the possibility of being the victim of a distributed denial of service (DDoS) attack and allows malicious or exploitative users to be swiftly detected and forbidden from accessing the service. Lastly, it ensures if a customer does want to consume larger amounts of services or data from us, other customers are not subsidising these requirements, where more resourcing is needed to support this. 

How does it work?

In general, rate limits work by keeping track of the number of requests made to the service, and preventing clients from using the service once the number of requests made within a short period of time exceeds a predetermined threshold. 

Cogito Group's implementation of rate limiting allows Jellyfish to rate limit each tenancy, user/IP address, and endpoint, by either the number of requests or the amount of data received by a customer within a typical billing period (1 Month). 

For example, Jellyfish limits the amount of audit log data that any single customer can retrieve within a month to 100 Megabytes or 100,000 requests, whichever comes first. These limitations can be lessened or removed if a customer wishes to purchase increased availability to the Jellyfish API. 

Each individual request also has a maximum response size of 4.2 Megabytes (4,194,304 Bytes). This means that for the example given above, customers would be required to call the audit search API at least 24 times within a month to reach the 100 Megabyte limitation. 

Here are some rate limits to help explain how Jellyfish rate limits are configured: 

In the table shown above, the example audit search rate limit forces all users within each tenancy to use the audit searching endpoint a maximum of 100,000 times a month, or roughly 3,225 times a day. The maximum number of requests a customer can make within a short period of time is 25,000, so as to prevent malicious users or potentially DDoS attacks. The limit also restricts a total of 100 MB of data to be retrieved per month. As the limiter restricts the endpoint to "All" users instead of "Each" user, if user "A" uses all the request of audit search endpoint, user "B" would not be able to use the audit search endpoint until the rate limit generates more request tokens for the tenancy to use. 

The image below is an example of a customer’s total API usage. The blue line represents the customer’s daily API usage, the yellow line represents the customer's consumption of API tokens over time, and the red line represents the customer's burst limit. 

This customer seemed to reach over 40,000 API uses out of their maximum 50,000 allotted tokens on Friday the 3rd, and may wish to consider purchasing additional tokens. 

What are the benefits?

While rate limiting may initially seem like a drawback, its primary benefit is preventing any single user from monopolising Jellyfish's resources for an extended period. This ensures better availability for all other customers on the platform, including those within the same business unit.

The limitation also prevents malicious attackers from disabling Jellyfish services by hogging resources or making too many requests. Damage from these destructive attacks is minimised because the limit reduces the pace of the attack, increasing our operators' time frame for detection and shutdown.