Comment by simonw
1 day ago
> Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user. If one thing fails, everything is rolled back.
This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for this - it's really useful to be able to say "queue this work if the transaction commits, don't queue it if it fails".
Brandur Leach wrote a fantastic piece on this a few years ago: https://brandur.org/job-drain - describing how, even if you have a separate queue system, you should still feed it by logging queue tasks to a temporary database table that can be updated as part of those transactions.
This is called the "transactional outbox pattern"!
Good name! Looks like SeatGeek use that naming convention here: https://chairnerd.seatgeek.com/transactional-outbox-pattern/
This looks like a good definition too: https://www.milanjovanovic.tech/blog/outbox-pattern-for-reli...
I agree this is an awesome feature. I use pg_timetable instead of Oban though: https://cybertec-postgresql.github.io/pg_timetable/v6.x/
We're building an AI powered app builder. We use elixir, phoenix and of course OBAN.
It feels like such a super power. What you're describing is particularly important in the era of long running AI processes. Something as simple as running a deploy creates pressure on your agent orchestration. But if everything is powered by OBAN you have wonderful ways to build durability.
By the way, it's all "free" and built-in.
In other language ecosystems, people literally pay for durability that has this shape (like temporal)
Excellent point. Never thought of transactions in this way.
Lots of people are also trying to just use postgres for everything, tho.
Debezium was built exactly for that to power a queue based on WAL.