3 ms·
Given the rate and size of messages we process, SQS presents a compelling "fallback" option (i.e. we need to route traffic when an irreplaceable RabbitMQ is dow
by zbentley 6y ago
Given the rate and size of messages we process, SQS presents a compelling "fallback" option (i.e. we need to route traffic when an irreplaceable RabbitMQ is down, pending human-initiated recovery), but not a compelling happy-path option because of cost, which you mentioned.
Edit: additionally, there was an inertial component to that decision. Not only do some folks have pretty deep expertise with RabbitMQ, but by the time we started to hit significant limitations with it, we had devised pretty good (manual and automated) ways around those limitations, like the multi-broker approach. I can't predict what would have happened had we jumped to a totally different messaging technology when we ran up against those things, but I'm reasonably happy with where we ended up.
- yowlingcat 6y agoYeah, that was my suspicion. From a cost optimization perspective, I don't think SQS will ever hit the level of price per instruction that RabbitMQ does. SQS also doesn't get anywhere near spitting distance on latency either. For my needs, though, it's always done a great job on reliable throughput. If you have folks with deep expertise with RabbitMQ, I can see why you'd go with it. It means that you can essentially neutralize its operational risks and maximize its strength, which is performance (as well as great integration codebase maturity).