MQTT: lightweight, massive device counts, real-time telemetry
MQTT is a pub/sub protocol built for low bandwidth, unreliable networks and large device counts. Messages are small and overhead is low, which suits high-frequency telemetry like temperature, vibration or meters, and field/mobile networks. When the pain is "tens of thousands of devices must report reliably," MQTT is usually the first choice.
Kafka: high-throughput streaming and data pipelines
When data must be consumed by several systems at once, replayed from history, or wired into an analytics pipeline, Kafka earns its place. It treats data as a durable, re-readable stream, ideal for real-time analytics, event-driven architecture and cross-system integration. The cost is heavier operations — not always worth it at small scale.
HTTP / REST: simple, low-frequency, easy to integrate
If device counts are modest and reporting is infrequent, or you just need to push data into an existing web API, HTTP/REST is the most direct — almost any system can consume it. The downside is per-connection overhead, unsuitable for high-frequency or massive real-time telemetry.
How to choose
- Many devices, high frequency, limited bandwidth, real-time telemetry → MQTT
- High throughput, replay needed, many consumers, analytics pipeline → Kafka
- Few devices, low frequency, quick integration with existing systems → HTTP / REST
In practice you rarely use just one. A common hybrid: edge devices report over MQTT → a gateway aggregates and writes to Kafka → downstream does real-time analytics, storage and alerting, exposing an HTTP API when external integration is needed. The key is to look at device scale, reporting frequency and how downstream uses the data before deciding each leg.