I’m evaluating MQTT versus REST API for device shadow synchronization in our c8y-1020 deployment. We have 500+ devices that need to maintain shadow state with the platform. MQTT offers real-time updates with low overhead, but REST provides simplicity and easier debugging. The latency trade-offs are significant - MQTT gives sub-second sync while REST polling introduces 5-30 second delays.
What are your experiences with each approach? Specifically interested in:
Real-time requirements vs implementation complexity
Network bandwidth consumption
Reliability and error handling
Scaling considerations beyond 1000 devices
Has anyone implemented a hybrid approach using both protocols?
REST is underrated for shadow sync. If you don’t need sub-second updates, polling every 30 seconds is perfectly fine and much simpler. We use REST exclusively - easier to debug, better tooling, and no persistent connection management headaches. For our monitoring use case where updates happen every few minutes, REST is ideal.
Scaling beyond 1000 devices changes the equation. MQTT requires careful broker configuration and connection management, but handles high device counts efficiently. REST polling creates server load that scales linearly with device count. At 5000+ devices, REST polling becomes problematic unless you implement smart caching and differential updates.
Bandwidth is a huge factor. MQTT with QoS 1 uses minimal bandwidth - we measured 80% reduction compared to REST polling. For battery-powered devices or expensive cellular connections, MQTT is the clear winner. REST’s overhead from HTTP headers adds up quickly when you’re polling frequently.
We use both in a hybrid setup. MQTT for critical real-time shadow updates (operational parameters, alerts) and REST for periodic non-critical sync (configuration, metadata). This gives us the best of both worlds - real-time where needed, simplicity elsewhere. The key is clearly defining which shadow properties use which protocol.