top of page
Search

MQTT

Architectural Style & Patterns: MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol, originally designed for resource-constrained devices and low-bandwidth, high-latency networks. The architecture of MQTT is broker-based pub/sub: clients do not communicate directly with each other but through a central broker. Clients can publish messages to a topic, or subscribe to topics to receive messages. This decouples producers and consumers – they don’t need to know about each other, only about the topic namespace. MQTT uses a simple binary protocol on top of TCP (and can be used over websockets as well for browser support). It emphasises minimal overhead – the header is just 2 bytes in many cases – which makes it great for IoT (Internet of Things) scenarios where network bandwidth and device battery life are at a premium. It also has features like QoS levels (to ensure message delivery at least once, at most once, or exactly once) and retains last will messages for clients that disconnect. MQTT aligns with event-driven architecture in that data is pushed as events from devices or services. It’s not for request-response, but you can simulate that pattern if needed by having a device subscribe to a response topic. MQTT fits micro-services if used as a message bus for events, but more often it’s seen at the edge – connecting sensors, mobiles, or application instances to a central service. A lot of modern IoT platforms (AWS IoT Core, Azure IoT Hub, etc.) support MQTT for device connectivity. It’s widely adopted in IoT: in fact, MQTT is considered the de facto standard for IoT messaging, known to connect millions of devices reliably. It’s also used outside of IoT in some messaging systems where its characteristics are desirable (for instance, Facebook Messenger’s chat implementation famously uses MQTT under the hood to achieve fast, efficient messaging on mobile.


MQTT architecture with lightweight publish-subscribe communication between IoT devices, sensors, and a central MQTT broker. The diagram highlights low bandwidth usage, persistent connections, and real-time telemetry data transfer ideal for constrained environments.

Strengths and Use Cases: MQTT’s design makes it extremely well-suited for certain use cases, particularly in the IoT and mobile realm:


  • Lightweight and Bandwidth-Efficient: MQTT was designed to minimize network traffic. Its messages have very low overhead (a few bytes of header) and the protocol itself is simple. This makes MQTT viable over unreliable networks, low-bandwidth links (like rural cellular or satellite), and for devices that need to conserve data (e.g., a sensor on a limited data plan). It’s also power-efficient for battery-operated devices, as communications can be kept short. A Facebook engineering blog noted that by using MQTT for Messenger, they achieved phone-to-phone message delivery in hundreds of milliseconds while being gentle on battery and data.


  • Publish/Subscribe Decoupling: The pub-sub model allows multicast distribution of messages. One device can publish once to the broker, and the broker will deliver that message to any number of subscribers interested in that topic. This is great for scenarios like sensor networks (one sensor reading goes to multiple analytic services) or live notifications (one user action should notify many others). It also decouples timing – senders and receivers don’t have to be connected simultaneously (the broker can hold messages for subscribers that are temporarily offline if QoS is configured for persistence).


  • QoS and Reliability Options: MQTT provides three QoS levels: 0 (at most once, fire-and-forget), 1 (at least once, receiver might get duplicates), and 2 (exactly once, through a handshake protocol). This allows developers to trade off reliability vs. overhead depending on the use case. For critical data (e.g., a payment message or critical alert), you might use QoS 2 to ensure it’s delivered exactly once. For high-frequency non-critical data (like sensor readings every second), QoS 0 might be fine. These options add flexibility not present in simpler pub-sub like SSE or WebSockets, which rely on TCP or custom logic for reliability.


  • Persistent Sessions and Last Will: MQTT brokers can hold onto session state for clients (like what topics they were subscribed to) and also store a “last will and testament” message that will be published if a client disconnects unexpectedly. This is powerful for building resilient systems – e.g., if a device drops offline, the broker can automatically notify others that this device went offline by publishing the will message. This kind of feature is not available in raw TCP or HTTP connections without building an overlay.


  • Simplicity for Device Implementation: MQTT is relatively simple to implement in code (the spec is straightforward), and there are client libraries for virtually every platform, including tiny microcontrollers. This ubiquity and simplicity (much easier than implementing, say, HTTP with TLS on a small chip) has made MQTT the go-to for embedded communication. Devices with as little as a few kilobytes of RAM can use MQTT, which is not feasible with heavier protocols.


  • Scalable Broker Technology - Modern MQTT brokers (like Eclipse Mosquitto, HiveMQ, EMQX) can handle extremely large numbers of connections and messages, scaling horizontally. Use cases exist where hundreds of thousands or millions of devices are connected to a broker network (IoT deployments in smart cities, large-scale telemetry). MQTT is proven in such scale scenarios. For instance, it’s mentioned that by 2025 there might be on the order of 10+ billion IoT devices online and MQTT is poised as a key protocol to connect a significant portion of them.


  • Beyond IoT – Mobile and Push - MQTT’s efficiency has led to its use in mobile apps for push notifications or chat (Facebook Messenger, as noted, and some other messaging apps). It maintains a live connection and can wake up mobile apps to deliver messages with minimal impact, which is better than long polling for battery life.


Weaknesses and Limitations: MQTT is specialised for certain contexts, and has limitations one should be aware of:


  • Not Human-Readable or Browser-Native: MQTT messages are binary and require a broker. You can’t simply call an MQTT endpoint from a web browser without using a MQTT-over-WebSocket bridge and a JavaScript client library. This means MQTT isn’t suitable for public web APIs consumed directly by front-end code (though the browser could talk to an HTTP service that then publishes MQTT messages, etc.). It’s more of a backend or device-level protocol.


  • Requires Broker Infrastructure: The necessity of a broker adds complexity. You must maintain one or a cluster. This is a single point of infrastructure that all clients rely on. If the broker goes down, communication stops (there’s no direct peer-to-peer fall-back). Also, the broker must be robust to handle all those connections and messages, which is a different scaling challenge than stateless web servers. For small deployments, running a broker is an extra moving part that a simple REST API wouldn’t need.


  • Message Size and Format Constraints - MQTT is ideal for small messages (its sweet spot is <256MB, and typically much smaller). While it can technically carry bigger payloads by splitting them, if you find yourself sending very large data (images, big JSON documents) through MQTT, you might be misusing it – it’s not optimized for bulk data transfer. Also, MQTT topics are not standardized beyond string conventions, and message content is opaque to the broker (it doesn’t know if you’re sending text or binary). Without a predefined schema, interoperability can suffer (everyone must agree on what message formats on each topic mean).


  • Security and Authentication - MQTT itself has username/password authentication and can be run over TLS for encryption, but it lacks the rich, granular security model of something like WS-Security or even OAuth in HTTP. Many brokers implement their own ACLs (who can publish/subscribe to what topics). But designing a secure multi-tenant MQTT system requires careful thought – e.g., preventing one client from eavesdropping on another’s topics or ensuring a malicious client can’t flood the broker. It’s certainly achievable (and products exist to secure MQTT), but not as standardized as HTTP’s approaches. The simplicity of MQTT means you have to handle a lot of security via convention and configuration.


  • Quality of Service Trade-offs - Using QoS 2 (exactly once) can significantly reduce throughput due to the handshake required for every message. So while MQTT can ensure delivery, at scale many systems stick to QoS 0 or 1 for performance, meaning you accept possible message loss or duplicates. If your scenario absolutely cannot lose messages and must not have duplicates, you might need additional layers (like persistent storage or deduplication logic) beyond MQTT’s base capabilities.


  • Eventual Consistency & Ordering - MQTT does not guarantee global ordering of messages across topics, and even within a topic, ordering is preserved per client connection but complex scenarios (like a subscriber reconnecting) might see a jump in sequence. If strict ordering is crucial, MQTT might not be sufficient. Also, like any distributed pub-sub, consumers might process events at different speeds, leading to eventual consistency issues you have to manage in the application logic.


  • Not Request-Response - By design, MQTT doesn’t do request-reply patterns out of the box. If a client needs a response, the typical approach is that it subscribes to a response topic and includes a correlation ID in the request message. This works, but is more cumbersome than a direct request-response protocol. So, MQTT is not ideal if your communication is inherently transactional or query-based (those are better served by HTTP or gRPC). MQTT is better when data flows in one direction (or omni directionally) as a stream of events.


MQTT is most effective for IoT communication, sensor networks, telemetry, and mobile push. For example, an array of environmental sensors reporting readings to a central system every few seconds – MQTT is perfect. Or a mobile notification service that pushes updates to apps – MQTT can be used to maintain open pipes to devices. Another use: car telemetry sending data to the cloud for analytics in near real-time. In contrast, MQTT is not ideal for something like a public REST API (“give me user info”) or heavy analytics data streams (for those you might use Kafka, which can handle huge volumes and persistence). It’s also unnecessary for systems entirely within a high-bandwidth data center – Kafka or AMQP might be more appropriate enterprise message buses there. In summary, MQTT fills the niche of simple, efficient pub-sub for constrained or distributed environments, and has proven itself by connecting massive numbers of devices reliably (one survey in the Industrial IoT domain showed 50% of respondents considered MQTT a strategic protocol, slightly above even HHTP).


Main Blog:

Comments

bottom of page