How to properly limit my own rate requests to external API?

You could discard the current request that got “too many requests” error.

1. Pattern match on the error body or HTTP status
2. If too many errors, return {:cancel, reason} to the Oban worker
3. The job will be canceled. Next request every N minutes will try again

This is a simple solution I can think of without much knowledge of the problem.

It’s not a single API request per perform(...) but multiple ones. Namely, in each perform(...) I iterate over Db rows making multiple API requests.

I don’t know much about how Oban works under the hood, but you could see if there’s a way to integrate Hammer into the execution loop. It’s a rate-limiter for Elixir that acts as a kind of traffic signaling device.

It seems like you need to limit the requests between records inside the perform call.

Is there a way to ask Oban to start the next job N minutes after the current one finishes execution? Instead of scheduling it on a predefined interval?

Also, you need to maybe “pause” between each api call with within the perform function.

I always try to create a plain genserver for things like this since it’s easier to handle and reach out for Oban when I need to deal with more complicated scenarios.

That would be overcomplication.

I don’t know. Is there?

Eliminate Oban > Cron and instead insert a new job manually at the end of perform(...). Dynamically. Huh?

Can you elaborate on why you think this?

Oban Pro has rate limiting Smart Engine — Oban v2.11.0. That however operates at the job level not the API request level. However if these are pretty 1:1 that might work fine.

That might work. Combining this with setting a pause between each request could solve the issue. Having said that, there could be a better “perform” logic that might work better? Having one api request per job somehow? Querying only the number of records that is less than the threshold of the api and schedule the next job accordingly?

I’ve done something 99% the same long time ago, GenServer based, but I am not willing to dig it up at the moment.

You could write your own GenServer that is responsible for contacting the 3rd party API (when you send it a message) and have it preserve state that relates to how much requests you have left for e.g. the next 5 minutes, and only when you are about to hit a rate limit you do Process.sleep.

Furthermore, using a GenServer for this immediately rids you of any potential race conditions i.e. doing 2 or more requests just before you hit rate limit because sending messages to GenServer is serial and on a first-come-first-served (FIFO) basis.

Or you can use opq or :jobs (that one is in Erlang but fairly easy to use). I have used both successfully.

FWIW I am not a huge fan of Oban even though it works perfectly, I feel it confuses people and that’s why I never reach for it unless I need persistence for the jobs – which is a real requirement and you have that mandatory a good chunk of the time so maybe you’re gonna be better off just using Oban with uniqueness rules and maximum concurrency settings. That works quite fine as well.

Additional dependency which hasn’t proven yet to even be required