The Boxed Ice guys have posted a very detailed article about the requirements, implementation, plus some pros and cons of building a custom queuing system on top of MongoDB. Embedded below is a slidedeck giving an overview, but I’d encourage you to read the whole post:
In case like you are wondering why the original title is “Replacing RabbitMQ with MongoDB” and the real reasons that led the guys to this migration, the answer is briefly mentioned at the end of the post and in an older post:
- All of the PHP AMQP libraries we tried were too unstable – either they didn’t work at all or they worked in low load testing but at high loads, performed terribly. We saw excellent response times and then suddenly there would be a massive spike and the entire postbacks process would hang. This appeared to be being caused by the connection pool resetting and every insert trying to recreate its connection.
- Fault tolerance – replica sets in MongoDB work extremely well to allow automatic failover and redundancy. The original reason we removed RabbitMQ was no in-built support for redundancy across multiple nodes/data centres. This is now possible as of RabbitMQ 2.6.0.
Original title and link: Creating a MongoDB Queuing System ( ©myNoSQL)