MQTT for Real-Time Systems: Publish/Subscribe From Basics to Production Fleet Tracking

When thousands of vehicles, sensors or devices need to send data in real time, HTTP request-response breaks down. MQTT (Message Queuing Telemetry Transport) is the lightweight publish/subscribe protocol that powers real-time backends at scale.

Why not just use HTTP?

HTTP works for "client asks, server responds". But real-time systems need the opposite: devices push data continuously and multiple consumers react to it. HTTP polling wastes bandwidth and adds latency. MQTT solves this with a persistent connection and a broker that routes messages to whoever subscribed.

Core concepts

• Broker - the central hub that receives all messages and routes them to subscribers (Mosquitto, EMQX, HiveMQ)
• Topic - a hierarchical address like fleet/vehicle-123/gps that messages are published to
• Publish - a device sends a message to a topic
• Subscribe - a consumer registers interest in topics (supports wildcards like fleet/+/gps)
• QoS - quality of service levels: 0 (fire and forget), 1 (at least once), 2 (exactly once)

Production example: fleet tracking

Imagine tracking 1,000 delivery vehicles in real time:

1. Each vehicle publishes GPS + speed + fuel to fleet/{vehicle-id}/telemetry every 5 seconds
2. The tracking dashboard subscribes to fleet/+/telemetry to display all vehicles on a live map
3. The alerting service subscribes to fleet/+/alert for speeding or geofence violations
4. The analytics service subscribes to all topics and writes to a time-series database

Each consumer receives exactly the data it needs without the vehicles knowing who is listening.

Advanced patterns

• Retained messages - the broker stores the last message per topic, so new subscribers immediately get current state (e.g. last known GPS position)
• Shared subscriptions - multiple instances of the same consumer share the load (e.g. 4 alert processors each handle 1/4 of messages)
• Last Will and Testament (LWT) - if a device disconnects unexpectedly, the broker publishes its pre-set "will" message, triggering offline alerts
• Persistent sessions - devices that reconnect receive messages queued while they were offline

Scaling considerations

• Single broker handles 100K+ concurrent connections (EMQX, VerneMQ)
• Cluster mode distributes load across nodes for millions of connections
• Bridge mode connects brokers across geographic regions

When to choose MQTT

Devsign builds real-time backend systems with MQTT, WebSocket and event-driven architectures for IoT and tracking platforms.