Oban is good, but we noticed we creeped up its usage without really trying by just throwing random things into it, so it is something that needs to be considered carefully. The use cases for oban and a message queue are very different and you must consider them carefully.
We have 8 nodes that are clustered and having oban on each one means that they really slam our database staying in sync. The nodes could just communicate their state in vm very cheaply but they use the db since that is how oban works.
We found ourselves doing things like creating unique jobs with delays to prevent jobs operating on the same data at the same time on different nodes and that was a sign that we were not using the right tool. In a message queue messages are ordered and they can be hashed so that messages that are related to each other always happen on the same node.
Oban will run through its jobs and if one fails, it will retry, Great. But they won’t necessarily happen in order. A message queue gives some guarantee on ordering. Often you can make it so that if there is a failure it will just keep retrying that message instead of skipping past. Then when you fix the bug, the process just continues right where it left off.
Oban (at least our version) has job limits but they appear to be capped on a per node level, so if we say create a job that has a limit of one, but we have eight nodes, there will be eight of them running at a time. Message queues often have partitioned topics and that prevents more nodes from operating it than you intended.
Oban is great, but remember what its use case is.
