MQTT is as good a protocol for scale as any other and has multiple advantages. It’s IP based, is very lightweight (say relative to HTTP) and has both queuing and topic (pub sub) constructs which make it ideal for IOT implementation. It’s popular too, which has it’s advantages.
From a scale perspective, it will come down to the choice of the broker.
You also need to think end to end. It’s not just getting devices connected. Can you address them at scale. For example, if a 10 million devices are connected, and you want John from NYC 6th Av’s water leak detector to be restarted, how do you ensure that the message only gets pushed from your .NET backend to that device? And how does this happen securely? Ideally, you just want to send a message to a topic (via .NET and probably using AMQP in the backend or even REST via micro services) and this should automatically get to the desired device, rather than maintaining a cache based device registry, having multiple bridges and brokers for front end/back end connectivity etc , which complicates things.
So given the above scenarios, at scale, you need: end to end device addressing, bidirectional messaging pipes (and not just capture one way), security, and deployment flexibly (cloud, on prem, edge).
In my experience, you would need a tiered architecture for this.
1. The connection layer - A wide and shallow connection layer, where each broker will do thousands/hundreds of thousands of connections, but at a relatively low throughout (say a few messages per second per broker).
2. The core layer - Then you need a narrow and deep back end tier, which allows multiple back and apps to talk to the devices via topics. Queuing is key here, as back end apps have to cope with a firehose. Load balancing is also critical as you would have multiple instances of the applications. Multi protocol support help as well, as you might want to stream data into various insights systems going forward.
3. The edge layer - when required, this is the layer for edge connectivity and aggregation. For example, 10s or 100s of sensors in a home or a factory floor can connect to a gateway, which then connects to the connection layer over MQTT. devices connecting to the GW could be over MQTT or other protocols - depending on what the device and sensor supports. You transform and standardise at the gateway layer to deal with legacy and innovation at the edge.
There are different brokers to choose from. For example Solace (I work for Solace) provides multi protocol messaging/event streaming brokers which talk MQTT/AMQP/REST and more with .NET/Java APIs - paho and qpid are open source and popular for all languages including .NET. Edge nodes can scale upto 200K concurrent streaming connections. Core could be software or even hardware, which can scale upto 30 million messages per second. Solace has multiple production deployment with millions of streaming connections with the above architecture.
There are other obviously providers as well, and all have their pros and cons. The good thing is that you have choice.
Thanks and Regards,
Sumeet.