Message Queue Evaluation - bcgov/common-service-showcase GitHub Wiki
Message Queue Evaluation
After much evaluation between the following technologies:
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