MQTT
A compact publish-subscribe protocol built for intermittent networks, constrained devices, hierarchical topics, and broker-pushed delivery.
Best for device-to-cloud and command-and-control messaging.
Protocol comparison
MQTT vs Kafka: device messaging or durable event streaming?
MQTT connects constrained clients through a lightweight broker. Kafka stores ordered event streams for high-throughput processing and replay. Many IoT systems need MQTT at the edge and Kafka behind the ingestion boundary.
Compare the operating model, not just throughput
The protocols solve different boundaries. MQTT optimizes the device connection; Kafka optimizes the durable processing backbone.
Apache Kafka
A distributed event log built for durable retention, partitioned throughput, consumer-controlled offsets, replay, and stream processing.
Best for service-to-service event pipelines, analytics, and replay.
| Capability | MQTT | Kafka |
|---|---|---|
| Core model | Brokered publish-subscribe with hierarchical topics | Partitioned append-only log with consumer offsets |
| Typical clients | Sensors, embedded devices, gateways, mobile clients | Backend services, connectors, stream processors |
| Delivery | Broker pushes matching messages; QoS 0, 1, or 2 | Consumers pull and commit offsets per consumer group |
| Retention and replay | Retained latest value and session queues; not a general event archive | Time- or size-based durable retention with offset replay |
| Routing | Hierarchical topic filters with + and # wildcards | Flat topics and partitions; routing belongs in producers or processors |
| Network assumptions | Designed for low bandwidth, high latency, and reconnecting clients | Designed for stable data-center or cloud service connectivity |
Choose by where the data is crossing
A single system can use both without duplicating their responsibilities.
Choose MQTT
When constrained or intermittently connected clients need low-overhead telemetry, commands, session behavior, and topic-level fan-out.
Choose Kafka
When backend teams need durable event history, multiple independent consumers, replay, partition ordering, and stream processing.
Use both
When MQTT terminates device sessions and selected events flow into Kafka for durable analytics, enrichment, and downstream products.
A practical MQTT-to-Kafka boundary
Keep protocol responsibilities explicit so replay, backpressure, and authorization remain understandable.
Normalize at ingestion
Validate payloads, attach device and tenant context, and reject malformed events before durable storage.
Choose the partition key
Preserve the ordering unit the business needs, such as device, asset, site, or account.
Separate command paths
Do not turn every backend event into a device command. Apply policy, expiry, idempotency, and approval before publishing back to MQTT.
MQTT vs Kafka FAQ
Can Kafka replace an MQTT broker?
Kafka is not a drop-in device broker. It does not provide MQTT sessions, QoS flows, retained messages, hierarchical topic filters, or the same constrained-client footprint.
Can MQTT replace Kafka for event history?
MQTT can queue session messages and retain a latest value, but it is not designed as a long-lived replayable event log for many independent backend consumers.
Where should an MQTT-to-Kafka bridge run?
Run it at a controlled ingestion boundary where credentials, schemas, retry behavior, partition keys, and dead-letter handling can be operated and observed.
Related architecture guides
Compare the browser transport question, then return to MQTT implementation and security.