Rate Limiting

[scheidtdav]

To prevent misuse, we should introduce rate limiting either through infrastructure or in code.
Current OSEM uses a max of 6 POST requests per minute.

What about GET requests? Shouldn't that also be limited to not overwhelm the database with requests?

[zven]

I would argue that we should put a rate limit to all kinds of requests. As for the limit itself: 6 per minute should be sufficient for "regular" users. In case we have some power users (special campaigns, research projects etc.) that need more requests per minute, we could introduce an important flag for those accounts (similar to OSM: https://wiki.openstreetmap.org/wiki/Rate_limiting) that can only be set by us after those accounts have reached out to us.

[scheidtdav]

Flagging accounts is an interesting approach!
Something we should almost definitely consider when reintroducing the admin backend. After all, we have to maintain that somewhere.

Sidenote: the flag is import and not important ;-)

I agree to having rate limits on all kinds of requests. We have to protect ourselves against misuse.
However a 6 / minute on all, won't work I think. You will very likely exceed that just navigating around on the map.
It probably has to be an order of magnitude more, if not two.

• GET = 60 / minute (same as nominatim for example) = 1 / sec
• POST / PUT / DELETE = 6 / minute = 0.1 / sec

Are we talking only API routes or also UI?

[zven]

Good point! I mainly thought about the API since for the UI, it's manly on us to not break our own system / make everything fast enough. 😉
Would we have any benefits from capping the requests coming from the UI? We would make sure that our backend is not overwhelmed but at the same time (potentially) also introduce a shitty UX, wouldn't we?

[scheidtdav]

I suppose there are some things we cannot really prevent from happening even when we make everything fast enough.
Say for instances you heavily load/ unload mobile device routes on the map. Or you use a bot to take loads of screenshots somehow. Any non-human or almost non-human 👽 interaction should probably be slowed down.

It's frankly a lot less likely than with the api, but maybe worth looking into after we have it implemented for the API?