The Distributed Message Bus Implementations e.g. in erlang clock about 20k tuples/sec
The Cloud SaaS Message Bus's though easy to use and get started with, fare even worse
If you are implementing a large scale IoT Solution?
Like Smart Cities, Smart Healthcare, Smart Energy, or Connected and Autonomous Vehicles. We'd suggest you give AutoBus a serious thought before you make your decision.
Answer this: How will you connect millions of devices to the backend if your Gateway's and Message Bus's perform in thousands of messages/second? No! Seriously
*** Every Cloud Service has thresholds and throttles, if you didn't know. These are normally 1000 requests/second to 20k reqs/sec. Or something like that. Ask your Cloud Service Provider Today. These limits are in the underlying design and architecture of the platform. Cloud or No Cloud there is no magic. Cloud might mean Easy perhaps, or OpEx but it Doesn't mean Infinite of anything brAutomatski softwares deliver on the stated Spec's and Performance The earlier Automatski Message Bus; Streams was written in Erlang and had performance issues. In Aug, 2015 we re-engineered it from the ground up using newer concurrency algorithms. And replatformed it from Erlang to Java
The Dev Builds are out.
On EC2 w/ c4.8xlarge 36 vCPU's & 60GB RAM AutoBus Clocked 1.0997 million messages/second We are still not there yet w.r.t. one spec i.e. 1 bn tuples/sec. But our engineers are working on making an order of magnitude leap from 100m tuples/sec to 1bn tuples/sec in due time.
*** and it can run on the (i) Edge, (ii) Fog or the (iii) Cloud