I have been reading this blog for some time now but never bothered to comment until today. Wanted to let you know that I am a fan and enjoy your work.

Thanks,

You raise some good points.

You’ve got the web services vs XMPP rates backwards, we’re able to saturate all of our aggregators HTTP pipes at about 30 a pop before they start either 500′ing or timing out, we’re seeing much more than that through XMPP.

As I mentioned above, we’re not just running MT traffic through our messaging queue – it’s flexible enough that we’re routing a bunch of other types of traffic between, everything from task scheduling to distributed logging between our rack.

The key point in all this isn’t the specific usage of the platform or tool, but rather that so often, we try to take the easy way out, and blame the language or framework, when in reality as you scale out, the architecture is really what we need to be paying attention to.

Your assertion that you can process 5,000 messages per second and horizontally scale is misleading and a ridiculous statement. Even if you’re connecting to multiple aggregators, each we’ll let you bind in at 20-40 MPS via SMPP and post to their web service at 50-100 MPS. You can load up your queues, but they’re still going to at the rate for which can pass messages to your aggregation partner(s), and they’re only going to send them out as fast as they can drain their own queues to each carrier (their binds to each carrier range from 200-2000 MPS across all clients).

Plenty of reasons;
We’re not just running MT traffic through our messaging server(s), we’re using them for logging, IPC, and a few caching tasks.

Those numbers of 10-20 messages per second are guaranteed throughput – in reality we’re bursting much more.
We’re also not running through just one aggregator. Yes, it is fairly expensive.

I’m sure the gents over at Twitter said “what’s the point” a lot too.