[hirsin]

Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?

Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.

[rswail]

If you're looking at SI units, the base unit for time is the second.

SI multipliers are all powers of 10, not 60, so minutes and hours are not really compliant.

[stackghost]

>Is there some obvious reason not to measure requests per minute rather than second?

It's much less obtuse to say something like "average req/min" or whatever, but then again you can't write a cool blog post about misusing an SI unit for radioactivity and shoving it into a nonsensical context.

[WaxProlix]

In my experience, rate limits are more often per second. It's easy to talk about kilo or mega-units, so this isn't as big an issue as the awkwardness of talking about very very low volume services. Maybe those (generally) inherently don't care about rates as much?

[spockz]

In my perception there is a difference between 1req/s as a rate limit, and 60/min. The difference has to do with bucketing. If we agree that the rate limit is 1/s, I expect to be able to exactly that and sometimes 2 within the same second. However, if we agree on 60/min, then it should be fine to spend all 60 in the first second of a minute, or averaged out, or some other distribution.

This also helps with the question I always get when discussing rate limits “but what about bursts?”. 60/min already conveyed you are okay to receive bursts of 60 at once, in contrast to with 1/s.

In my experience it is exactly the low rate service that care about rate limits as they are the most likely to break under higher load. Services that already handle 100k req/s typically don’t sweat it with a couple extra once in a while.

[atoav]

An effective rate limiting system has multiple bases in my experience, depending on what the goal is. But I usually implement the configuration as a list where you can define how much requests are allow maximum per how many units of time.

E.g. to prevent fast bursts you limit it to 1 request per 1 second, but to avoid someone sending out 86400 requests a day you also cap them at 100 per 86400 seconds (24 hours) and 1000 per 3600 seconds (1 hour).

Whichever limit they hit first will stop it. That isn't hard to implement if you know how to deal with arrays and it allows long term abuse, while still along fast retries if something went wrong.

[spockz]

Exactly, you still will want to agree on multiple rate limit bases, precisely because they are different.

[scbrg]

I guess there's a difference between talking about how many requests a system is capable of handling, and how many they actually get.

At least when i encountered the discussion initially (some thirty years ago) I'd say we usually talked about how many requests the system was capable of handling. Then requests per second was the obvious unit since a request usually took less than a second to process (obviously depending on the system and so on - but mostly), so using that unit often gave a fairly low, comprehensible number.

Was it ten? A hundred (very impressive)? Perhaps even a thousand (very, very impressive!)?

Multiply those numbers by 60, and there's suddenly a lot more mental gymnastics involved. By 3600 and you're well into "all big numbers look the same" land.