In the world of IoT, delivering messages reliably to the right device at the right time is a fundamental challenge. In one of my past projects, I worked on building a system where remote IoT devices subscribed to specific topics and displayed messages on a screen at a certain time. While the concept might sound simple, ensuring scalability, efficiency, and real-time delivery required careful architectural decisions.
The goal was clear: send messages from a backend system to remote IoT devices either scheduled or on a certain time, where they would be displayed on a screen till the message expires. However, several challenges came with this:
- Targeted delivery – Each message was meant for a specific device or group of devices or for a certain location where devices are.
- Scalability – The system needed to handle thousands of devices without breaking down.
- Reliability – Messages had to be delivered even in unstable network conditions.
- Real-time updates – Devices should receive messages almost instantly. This was critical.
To achieve this, we designed a system using MQTT (Message Queuing Telemetry Transport) as the communication protocol. Here’s a high-level breakdown of how things worked:
- Backend System – A cloud-based microservice backend was responsible for managing messages and determining which devices should receive them and when it needs to be delivered.
- MQTT Broker – The core messaging infrastructure, acting as an intermediary between the backend and IoT devices.
- Topic-Based Subscription – Each IoT device subscribed to specific MQTT topics based on its unique identifier (device id) or category or location.
- Device Display – Upon receiving a message, the device processed the message and then displayed it on the connected screen till the time the message expires.
This architecture ensured that only the intended devices received specific messages without unnecessary overhead.
Key Challenges & How We Solved Them
- Message Routing Complexity – With multiple devices subscribing to different topics, managing message routing was a challenge. We structured topics hierarchically (e.g., devices/, location/devices, category/devices, etc) to make it easier to control distribution.
- Network Reliability – Since IoT devices might be in areas with weak connectivity, we implemented Quality of Service (QoS) levels in MQTT to ensure message delivery even in spotty network conditions and at least once.
- Scalability – To handle a growing number of devices, we optimized the MQTT broker setup and used a load-balanced architecture to prevent bottlenecks.
- Security – We implemented TLS encryption and certificates based device authentication to ensure that only authorized devices could subscribe to and receive messages.
- MQTT is a powerhouse for IoT messaging – Its lightweight nature and topic-based filtering make it ideal for real-time communication.
- Designing for scale early on saves headaches later – Structuring topics properly and optimizing the broker setup made it easier to add more devices without redesigning the system.
- Network resilience matters – Even the best messaging system needs safeguards for unreliable connections. QoS settings helped us maintain reliability.
- Security is non-negotiable – Any IoT system must prioritize encryption and authentication to prevent unauthorized access.
This project reinforced the importance of well-architected communication in IoT systems. Whether you're working on a small IoT deployment or scaling up to thousands of devices, a strong messaging foundation is key.
Have you worked on a similar IoT messaging system? I’d love to hear your thoughts and experiences!
Nice Article, thanks for sharing your experiences Inwinder Kochhar. Choosing the right framework to build your system is important to ensure it's scalable and reliable. MQTT being a lightweight protocol works well in scenarios where the connected devices may not have enough horsepower to process more complex protocols such as REST/SOAP and where the network is not very stable such as a device in a remote area with weak network connectivity.