An architecture that grows with the sites
A single site with one broker is connected quickly. It gets harder when sensors at many locations have to deliver to a central backend over unreliable networks. Together with FH JOANNEUM, Thomas Jöbstl investigated in his bachelor thesis how MQTT broker clusters have to be structured for this, and built and load tested three variants of a hierarchical architecture
Key facts
- Work
- Bachelor thesisFH JOANNEUM Graz2026
- Author
- Thomas JöbstlBusiness Informatics
- Variants
- Lightweight gatewayRabbitMQ clusterEMQX cluster
- Measured
- ThroughputLatencyResourcesWAN outagesFault tolerance
Three questions for a distributed architecture
How must MQTT broker clusters be structured so that distributed sensors communicate reliably with the backend? How do centralised, hierarchical and distributed topologies differ in scalability, fault tolerance and latency? And which variant suits a company like Sync Motion?
The answer was not found on a whiteboard. All three variants were built with Mosquitto at the edge and Apache Kafka and ClickHouse at the core, then tested with up to 10 000 messages per second, degraded wide area networks and deliberate failures of single components
Findings
What the measurements show
Hierarchy holds up
Edge brokers buffer messages during network outages in all three variants, while the central distribution layer stays simpler to operate than a fully distributed system
Level at moderate load
Up to 5 000 messages per second all variants lose around one percent, and up to 2 000 the latency sits at 40 to 70 ms at the 95th percentile everywhere
Differences at peak load
At 10 000 messages per second EMQX loses seven percent, the lightweight gateway 13 percent and RabbitMQ 40 percent, with its latency rising above eleven seconds
Resilience on a poor network
On a degraded WAN RabbitMQ loses the least at 5.7 percent, and after a 60 second outage it delivers the buffer fastest with 0.7 percent loss
Loss of a broker node
Both cluster variants survive the loss of one node without message loss, while single components such as load balancers remain vulnerable and need redundant deployment
Recommendation for Sync Motion
RabbitMQ as the central layer: bidirectional communication, the best WAN resilience and an open licence, growing through several independent clusters per region
What this means for projects
KEY TAKEAWAY
Topology decides earlier than technology
Every site gets its edge broker
A local broker keeps the plant running even when the link to the centre drops. Messages are buffered and delivered later instead of being lost
Scaling without rebuilding
New sites join as further edge brokers, the distribution layer grows through additional independent clusters per region. The architecture stays the same
Measurements instead of gut feeling
The choice of broker technology rests on measured behaviour under load, during network faults and failures. The numbers feed directly into the design of new projects
Open technologies, open future
Mosquitto, RabbitMQ, Kafka and ClickHouse are available under open licences. Customers commit to an architecture, not to a vendor