Answer the question
In order to leave comments, you need to log in
What is the correct message bus architecture for a client/server IoT system?
There is a system, it consists of a server and a set of IoT devices.
Each IoT device hosts a set of microservices (Docker).
Each microservice needs to send/receive integration messages to other microservices on the same device, plus send/receive messages to the server.
The server must be able to send messages to all IoT devices (status request), a group of IoT devices (grouping can be based on various criteria, for example, the number of the room where the devices are located, city, etc.), a specific IoT device (for example, a command to restart / reconfiguration).
Question: how it is most correct to organize it from the point of view of message bus? Do two message bus instances - local RabbitMQ in Docker on each IoT device, and global for server-client exchange? Have one common message bus and somehow route messages? (then there will be an overhead for microservice interaction through the cloud, although the messages themselves are small in size).
It is planned to use MassTransit as a message bus framework, if it is important (the server can be hosted both in Azure and locally with RabbitMQ).
Thanks in advance.
Answer the question
In order to leave comments, you need to log in
I have not worked with IoT devices, but it seems to me that a separate local bus sounds logical, as it will allow you to have the lowest latency and work offline, and also, possibly, save battery. But depending on the task and resources, it may be more profitable to work through the server at first. Using RabbitMQ on an IoT device is a so-so idea, IMHO, for simple sending on a small scale, it will be unprofitable in terms of resource consumption.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question