There are a couple of things that may work for you; it’s difficult to say what the best solution would be without knowing more about the specifics of the problem.
Yes, Oban supports scheduling, either after N seconds or at a specific datetime:
If this is the route you go for, make sure you read the “Reliable Scheduling” docs to avoid some unexpected behaviour:
Something else to look at is custom backoff:
Hope that helps.
People have already mentioned Oban.
I’ll just point to a real world config example I came across recently:
https://github.com/notesclub/notesclub/blob/1da08eb06118217eee519c3b565c2a6b0d49e834/config/config.exs#L84-L87
As I’ve explained, I’m using Oban in the cron mode. Therefore, it’s already scheduled, with repetition, via the config, statically.
So Oban is capable of slowing down the requests on its own then? This will work for me.
However, what will happen if
the next iteration of
Oban.perform(...)that switches in execution may coincide with the current one which is STILL getting executed
?
Yes, only with Pro’s smart engine. In OSS; manually chaining jobs, edge cases, etc yourself.
Hey 
a bit late to the party, but I think is worth sharing this library Regulator which provides adaptive concurrency limits around external resources.
It does not integrate with Oban, but it might be worth a look to understand how they implemented the logic.
Cheers 
Oh that’s a good one, bookmarked it right away but that’s not surprising because the author is fantastic.
You could also check out ExWaiter — ex_waiter v1.3.1
For better or worse, it’s not opinionated about how you keep track of whether requests can be made.
I ran into a similar issue needing to rate limit my own requests. What I did was use ExHammer to check if I’m over or under the limit and from there can snooze the Oban job for however long until the next bucket is available to make more requests.