My priorities as a business needing a job queue are: - Does it run my jobs reliably? - Does it run my jobs with good performance? - Are failed jobs obvious a

My priorities as a business needing a job queue are: - Does it run my jobs reliably? - Does it run my jobs with good performance? - Are failed jobs obvious and simple to report/retry/log? Bull's tests and history shows that these needs are addressed. For a backend, the Redis strategy employed by Bull is battle-tested and used by many other related projects. I can't say that about any other backend. I haven't found this to be a common, real issue in practice. For multiple queues, I can easily run multiple namespaced Bull instances, so that is not an issue. Bull uses subscriptions and RPOPLPUSH, so I'm not sure where the polling problem is that you mention. Bull's performance testing is very competitive. Functions vs classes is an interesting dev choice... In JavaScript there is really not much of a difference. I would argue that functions are more lightweight, which is good for a job queue, but I don't actually think a job queue needs an opinion on client JS architecture. If you have performance numbers and a test suite for TaskBotJS, that would go a long way to support the claims.