Message Queue Evaluation

Message Queue Evaluation

After much evaluation between the following technologies:

• RabbitMQ
• RSMQ
• RSMQ-Worker
• Bull

I will be moving forwards with Bull which is implemented on top of Redis. While the other technologies "can" achieve what we want, they have shortcomings:

• I found that RabbitMQ is dependent on third-party plugins in order to extend its functionality to do delayed sending. This means it may have trouble playing nicely on Openshift.
• RabbitMQ is also designed as "queue first", meaning it will not be a good tool to handle some light persistence, whereas Redis is designed as "memory key-value store first".
• RSMQ is a decent and simplistic queue library on top of Redis. While it achieves queuing decently on Redis, it does not have much in the way for handling the producer-consumer pattern.
• RSMQ-Worker is a wrapper that facilitates the producer-consumer execution pattern. However, after attempting to leverage the library, it became obvious that the library hasn't been maintained in 2+ years, and has a few shortcomings in regards to its support for ES7 async/await code patterns.
• Bull is a full-fledged queue on Redis. It handles effectively most of what we would need in the queue and includes a wide array of functionality, including delayed message consumption. It also by default allows for persistence of queue state.
• Redis appears to have slightly more support on Openshift - it's a more well traveled road as compared to RabbitMQ. (There are more templates available for Redis via Helm and Kubernetes, as well as distribution images)

Originally sourced from SHOWCASE-249