zlacker

>>mpweih+(OP)
Author of https://node-ts.github.io/bus/ here. SQS is definitely one of my most favourite message queues. The ability to have a HA managed solution without having to worry about persistence, scaling or connections is huge.

Most of the complaints are native to message based systems in general. At least once message receives, out of order receives, pretty standard faire that can be handled by applying well established patterns.

My only request would be to please increase the limits of message visibility timeouts! Often I want to delay send a message for receipt in 30 days. SQS forces me to cook some weird delete and resend recipe, or make this a responsibility of a data store. It's be really nice to do away with batch/Cron jobs and deal more with delayed queue events.

>>redact+Gb
isn't it dangerous to relay on persistence of MQ for such a long time? shouldn't your system have a way to re-create the queue at any time? if so, you should be able to call such command to fill in the queue within the maximum timeout time allowed by MQ provider.

>>gondo+Xd
> isn't it dangerous to relay on persistence of MQ for such a long time

Most of them are designed and intended as a persistent data store. Data loss for a queue system is typically something you do not want