I want to learn the best behavior for implementing a rate limiter. Say I have serviceA and serviceB where serviceA calls API_1 and API_2 in serviceB. Say that serviceB has implemented rate limiting for its APIs.
Is the usual practice to set rate limits per API, i.e., would API_1 have its own rate limit for serviceA and API_2 have another value of the rate limit? Or is it best practice to set rate limit values for serviceA irrespective of what APIs it calls in serviceB?
Since you included service names, I assume that these different APIs are a single system with multiple API endpoints (I would call that one API, but nomenclature differs). For example serviceB might be Spotify, with an endpoint for album art (API_1) and an endpoint for finding which album a song belongs to (API_2). In such a case, where it's basically one system with one API key (access token), I would expect the APIs to be rate-limited together. Once you exceed it for one, you can also not access the other.
However, if there are different API keys to use these endpoints and the two are fully independent, then it would not make sense to somehow try to synchronize rate limiting state between them. They would somehow have to talk to each other about which clients have already done a number of queries, such that the client is correctly limited. This is extra complexity and not worth it.
So it depends on the situation whether they can reasonably be connected together. And even then, it would depend on if this is desirable: maybe a geolocation endpoint that is part of an emergency service wants to rate limit calls to their reverse geocoding, but meanwhile you still want to be able to post alerts for a fire in sector C. In that case, they might be handled by the same server and use the same API key for access, but still have a different (or no) rate limit on one/some of the endpoints.
