I have a scenario in which thousands of IoT devices -- each fitted with a sim card -- are geographically distributed and shall be controlled individually.

Therefore each IoT device has a WebSocket client with which it can connect to a central system. Since there might be a lot of communication, the IoT devices connect to a backend WebSocket server component (Gateway) that is horizontally scalable and behind a load balancer.

In the backend landscape there are other components (Master) that want to send commands or queries to the IoT devices based on their UID. Therefore a Master must find the correct Gateway which has an open WebSocket connection with that specific IoT device.

My initial idea now is to introduce a message broker (Kafka?!) between all Master and Gateway components. Each Command or Query message together with the targeted UID is thrown onto the message broker and into a request topic/queue/stream.

Each Gateway reads all request messages and if one Gateway has an active WebSocket session to the IoT device with the given UID, the Command or Query is sent to the IoT device.

I would be happy about a review of my described design! Are there some common heuristics or algorithms (distributed system design) that I could rely on?

I don't want an registration service because it would introduce an extra call or each Master would build its own registry and if a Gateway crashes the registry would need an update.

  • "Is there a better solution ..." are often a sign of a bad question; are you looking for a design review, might want to rephrase to indicate what you want.
    – esoterik
    Jul 2, 2018 at 18:40
  • @esoterik yes I would like a design review :) Jul 2, 2018 at 18:44
  • FWIW this sounds like a very sane design to me.
    – RubberDuck
    Jul 2, 2018 at 23:45
  • @RubberDuck I am a little concerned about the fact that every Gateway has to read every Command/Query message to check if it holds an active WebSocket session and was wondering if there might maybe be a good middleware or process to support that fakt Jul 3, 2018 at 5:20
  • 1
    What about using Elixir for your gateways? You could network them with the Erlang VM and only have a single consumer group for all of the gateways. All of the gateways read, but because there’s a single consumer group they don’t read all of the messages. When a message is read, it notifies all of the other nodes via a broadcast.
    – RubberDuck
    Jul 3, 2018 at 11:05

1 Answer 1


The approach with a message broker is what SignalR in Net uses, it has multiple options for the message broker. I included link below which describes their approach for reference even if using other technologies. This is what we used with Azure Service Bus as the backplane.


  • 1
    might want to expand on this.
    – esoterik
    Jul 2, 2018 at 18:37
  • @scott-mildenberger thank you for the hint, in the article is stated "In [a client to client] scenario, the backplane might be a bottleneck if the number of messages scales with the number of clients; that is, if the rate of messages grows proportionally as more clients join." do you know what SignalR proposes in such a scenario? Jul 3, 2018 at 5:48
  • @jstr sorry I didn't remember that limitation as our application has a small number of clients. Jul 3, 2018 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.