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 certain period of time.
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 audit log 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:
| User(ID) | Method | Endpoint | Rate (Tokens per Period) | Burst(Max Tokens Stored) | Size(Bytes per Period) | Period(Seconds) |
| [All] | POST | /api2/AuditConfig-v1/SearchLogs | 100,000 | 25,000 | 100,000,000 (100 MB) | 2,678,400 (1 Month) |
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.
What are the benefits?
While a forced limitation for all users of Jellyfish may at first seem like a detractor of the service, it prevents any single user from monopolising the Jellyfish’s resources for an extended period of time, allowing for better availability for all other customers on the Jellyfish platform, including customers from the same business unit.
The limitation also prevents malicious attackers from disabling the Jellyfish service by hogging resources or making too many requests. Damage dealt by these destructive agents are also minimised, as it reduces the pace of the attack and increases our operative’s time frame for detecting and shutting the attacker down.