I’m extremely biased, but I would use oban. It has periodic jobs, scheduled jobs, retries, resiliency, etc. Broadway is tailored for ingesting high throughout event streams.

I have written a few article/tutorials on Broadway and perhaps those can help inform your decision:
https://akoutmos.com/post/using-broadway/
https://akoutmos.com/post/broadway-rabbitmq-and-the-rise-of-elixir/
https://akoutmos.com/post/broadway-rabbitmq-and-the-rise-of-elixir-two/

I think some more information may be required to better answer your question:

• How often are you fetching data from this JSON API?
• Is it a singular piece of information that needs to be processed (i.e no benefit from concurrent processing)?
• Do you require a message queue to persist messages across deployments of your service?

On the simple side of the spectrum, you could have a simple GenServer with a send_after to do everything that you outlined and just start that process up in your application.ex supervision tree. On the complex side of things, you could run RabbitMQ and Broadway to do your processing, but that depends on the answers to the Qs above . Like others have mentioned, Oban is also a good tool for the requirements that you outlined.

I’ve used Broadway extensively. Have not used Oban.

You can use Broadway to poll you just put stuff in your own producer. So you can totally use Broadway here and it would be great.

With Broadway, you do need to understand the lifecycle of a process and your app if you want to make sure you get every event.

Oban is backed by a database so your state is always there. You don’t have to worry about deploys affecting processes, etc. You sacrifice some throughout for this.

So those are mostly your high level trade offs.

If you’re not super comfortable with gen servers I’d say use Oban. If you need all the throughput use Broadway.

Edit: I should maybe clarify. Broadway won’t do the polling for you. Make your poller and put the results in a queue somewhere (ETS probably) and the have your producer pull from that.