zlacker

>>bo0tzz+(OP)
Hi HN, I'm one of the authors of River along with Brandur. We've been working on this library for a few months and thought it was about time we get it out into the world.

Transactional job queues have been a recurring theme throughout my career as a backend and distributed systems engineer at Heroku, Opendoor, and Mux. Despite the problems with non-transactional queues being well understood I keep encountering these same problems. I wrote a bit about them here in our docs: https://riverqueue.com/docs/transactional-enqueueing

Ultimately I want to help engineers be able to focus their time on building a reliable product, not chasing down distributed systems edge cases. I think most people underestimate just how far you can get with this model—most systems will never outgrow the scaling constraints and the rest are generally better off not worrying about these problems until they truly need to.

Please check out the website and docs for more info. We have a lot more coming but first we want to iron out the API design with the community and get some feedback on what features people are most excited for. https://riverqueue.com/

>>bgentr+9l
So excited y'all created this. Through a few job changes I've been exposed to the most popular background job systems in Rails, Python, JS, etc, and have been shocked at how under appreciated their limitations are relative to what you get out of the box with relational systems. Often I see a lot of DIY add-ons to help close the gaps, but its a lot of work and often still missing tons of edge cases and useful functionality. I always felt going the other way, starting w/ a relational db where many of those needs are free, would make more sense for most start-ups, internal tooling, and smaller scale businesses.

Thank you for this work, I look forward to taking it for a (real) test drive!