>>jedber+(OP)
This is still a pretty common misconception (and one that I held until recently when looking at Redis configuration options again), but Redis does have durable operating modes to reload the datastore after going offline (which do significantly trade off speed for durability). If your task queue requires a high enough volume of workload that running Redis in a durable fashion is insufficient, then it's probably time to think about a different queuing system than WakaQ.
>>belthe+b6
I'm talking about if the VM/Instance/Disk goes away. It looks like Redis is a single point of failure unless you run Redis in a redundant way, but skimming the code it looks like that is at best left as an exercise to the reader. ie. Redundancy in the data store doesn't appear to be handled by this code.
>>jedber+U5
Yes, I don't know any distributed task queue that stays online or backs up tasks when the broker dies. Maybe one could be built on CockroachDB? My implementation is designed to process tasks fast and if the Redis server dies (hasn't happened in 10 years) you just boot up a new one. I try to design my tasks to expect some failures and be able to re-run safely.
>>welder+78
RabbitMQ and SQS both have redundancy built in.
There's nothing wrong with the trade off you made, but when I read distributed I assumed that you meant the task broker was distributed and therefore redundant, not the consumers.