34  MQTT Architecture Patterns

In 60 Seconds

MQTT’s publish-subscribe architecture routes messages through a central broker using hierarchical topics separated by /. Subscribers use two wildcards for flexible filtering: + matches exactly one level (e.g., home/+/temperature matches any room’s temperature) and # matches all remaining levels (e.g., home/# matches everything in the home). Publishers never use wildcards; they always publish to specific topics.

34.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain the Pub/Sub Architecture: Distinguish how MQTT decouples publishers from subscribers through a central broker compared to request-response models
  • Design Topic Hierarchies: Construct effective topic naming schemes that enable efficient wildcard subscriptions for real deployments
  • Apply Wildcard Rules: Configure single-level (+) and multi-level (#) wildcards correctly in subscription patterns and justify which wildcard to use
  • Analyze Component Roles: Assess the responsibilities of publishers, subscribers, and brokers, and evaluate their interactions in MQTT system designs

Key Concepts

  • MQTT: Message Queuing Telemetry Transport — pub/sub protocol optimized for constrained IoT devices over unreliable networks
  • Broker: Central server routing messages from publishers to all matching subscribers by topic pattern
  • Topic: Hierarchical string (e.g., home/bedroom/temperature) used to route messages to interested subscribers
  • QoS Level: Quality of Service 0/1/2 trading delivery guarantee for message overhead
  • Retained Message: Last message on a topic stored by broker for immediate delivery to new subscribers
  • Last Will and Testament: Pre-configured message published by broker when a client disconnects ungracefully
  • Persistent Session: Broker stores subscriptions and pending messages allowing clients to resume after disconnection

34.2 Prerequisites

Required Chapters:

Technical Background:

  • TCP/IP networking basics
  • Client-server vs pub/sub patterns

Estimated Time: 15 minutes

34.3 MQTT Publish/Subscribe Architecture

MQTT’s publish/subscribe pattern decouples message producers from consumers through a central broker:

MQTT pub/sub architecture
Figure 34.1: MQTT broker routing sensor messages to wildcard subscribers

34.3.1 Publish/Subscribe Pattern Components

Publishers:

Device Location Publishes To QoS
Temperature Sensor 1 Living Room home/living_room/temp QoS 1
Temperature Sensor 2 Bedroom home/bedroom/temp QoS 0
Humidity Sensor Kitchen home/kitchen/humidity QoS 1

Subscribers:

Consumer Subscription Receives
Mobile App home/# All home messages (temp + humidity)
Web Dashboard home/+/temp All room temperatures
Analytics Service home/+/humidity All room humidity readings

Message Flow: Publishers –> MQTT Broker –> Subscribers (based on topic matching)

Scenario: 100 temperature sensors publish to 1 broker serving 10 dashboards.

Topic hierarchy: \[ \text{Topics} = \texttt{building/floor\_X/room\_Y/temperature} \]

Message routing calculation: \[ \begin{align} \text{Publishers} &= 100 \text{ sensors} \\ \text{Messages/sec per sensor} &= 0.1 \text{ (every 10 seconds)} \\ \text{Total inbound msgs/sec} &= 100 \times 0.1 = 10 \text{ msgs/sec} \end{align} \]

Fan-out with wildcard subscriptions: \[ \begin{align} \text{Dashboard subscription} &: \texttt{building/\#} \text{ (all topics)} \\ \text{Each message delivered to} &= 10 \text{ dashboards} \\ \text{Total outbound msgs/sec} &= 10 \times 10 = 100 \text{ msgs/sec} \end{align} \]

Broker load: \[ \begin{align} \text{Topic matching operations/sec} &= 10 \text{ (inbound)} \\ \text{Message copies/sec} &= 100 \text{ (outbound)} \\ \text{Total broker operations/sec} &= 110 \end{align} \]

Bandwidth: \[ \begin{align} \text{Message size} &= 50 \text{ bytes (avg)} \\ \text{Inbound bandwidth} &= 10 \times 50 = 500 \text{ bytes/sec} \\ \text{Outbound bandwidth} &= 100 \times 50 = 5{,}000 \text{ bytes/sec} = 40 \text{ kbps} \end{align} \]

Broker capacity check (typical 100K msgs/sec): \[ \frac{110}{100{,}000} = 0.11\% \text{ capacity (plenty of headroom)} \]

Key Architectural Benefits:

  • Decoupling: Publishers and subscribers don’t need to know about each other
  • Many-to-Many: Multiple publishers can send to same topic, multiple subscribers can receive
  • Dynamic Discovery: New subscribers automatically receive messages from existing publishers
  • Location Transparency: Clients only need broker address, not peer addresses

MQTT broker framework

MQTT Publish-Subscribe Architecture
Figure 34.2: MQTT publish-subscribe framework with broker architecture

34.3.2 MQTT Broker Fan-Out Calculator

Estimate how many messages your broker must route based on publisher count, subscriber fan-out, and publish rate.

34.4 Topic Hierarchy and Wildcards

MQTT topics use hierarchical structure with powerful wildcard subscriptions:

Topic naming patterns

This diagram shows topic naming patterns: hierarchical, descriptive topics enable efficient wildcard subscriptions, while flat or cryptic topics make filtering difficult.

MQTT Topic Hierarchy Example: Smart Home

Level Path Topics
Root home/ Base namespace
Rooms home/{room}/ living_room, bedroom, kitchen
Devices home/{room}/{device} temp, humidity, light

Topic Tree:

Room Topic Value
Living Room home/living_room/temp 24.5C
home/living_room/humidity 45%
home/living_room/light on
Bedroom home/bedroom/temp 22.0C
home/bedroom/humidity 50%
home/bedroom/light/main off
home/bedroom/light/bedside on
Kitchen home/kitchen/temp 26.0C
home/kitchen/humidity 60%

34.4.1 Wildcard Subscription Rules

Wildcard Subscription Examples:

Wildcard Pattern Matches Count
Single-level (+) home/+/temp All room temperatures 3 topics
Multi-level (#) home/bedroom/# All bedroom sensors 4 topics
Two single-level home/+/+ 2-level topics only 7 topics (not light/main)
Full multi-level home/# Everything under home 9 topics
  • + (Single-level): Matches exactly one topic level (e.g., home/+/temp matches home/bedroom/temp, not home/bedroom/closet/temp)
  • # (Multi-level): Matches zero or more levels, must be last character (e.g., home/# matches all topics under home)
  • Best Practice: Design topic hierarchy to enable efficient wildcard patterns ({location}/{device_type}/{metric})

Important: Wildcards are Subscribe-Only

MQTT wildcards are subscribe-only, not publish:

  • Subscribe: client.subscribe("home/+/temp") - receives all room temperatures
  • Publish: client.publish("home/+/temp", "25") - this does NOT work! Must publish to specific topic.

You CANNOT publish to a wildcard topic in the intended sense. The broker treats home/+/temp as a literal topic string — the + character is part of the topic name, not a wildcard. Subscribers using patterns like home/# or the exact literal home/+/temp would still receive the message, but subscribers using home/bedroom/temp or home/kitchen/temp would not. The publish has no fan-out effect: it reaches only those subscribers whose pattern happens to match the literal string home/+/temp.

34.4.2 Topic Hierarchy Planner

Calculate the total number of MQTT topics and subscriptions needed for a multi-floor building deployment.

34.4.3 MQTT Bandwidth Estimator

Estimate daily message volume and bandwidth consumption for your MQTT deployment.

34.5 Worked Example: Design MQTT Topic Hierarchy

Scenario: You are architecting the MQTT topic structure for a 10-floor commercial building with multiple sensor types per floor. The system needs to support dashboards filtering by floor, by sensor type, and by specific rooms.

Given:

  • Building: 10 floors, 20 rooms per floor
  • Sensors per room: temperature, humidity, occupancy, air quality (CO2)
  • Actuators per room: HVAC, lights, blinds
  • Requirements: Floor-level dashboards, building-wide analytics, room-specific control
  • Expected message volume: ~200,000 messages/day

Solution:

Step 1: Define Topic Hierarchy Structure

Use a hierarchical pattern that enables efficient wildcard subscriptions:

{building}/{floor}/{room}/{device_type}/{metric}

Step 2: Design Topic Examples

# Sensor data (published by devices)
building1/floor03/room12/sensor/temperature
building1/floor03/room12/sensor/humidity
building1/floor03/room12/sensor/occupancy
building1/floor03/room12/sensor/co2

# Actuator commands (subscribed by devices)
building1/floor03/room12/hvac/setpoint
building1/floor03/room12/lights/state
building1/floor03/room12/blinds/position

# Device status (published by devices)
building1/floor03/room12/hvac/status
building1/floor03/room12/lights/status

Step 3: Map Subscription Patterns to Use Cases

Use Case Subscription Pattern Messages Received
Building analytics (all data) building1/# All 200K/day
Floor 3 dashboard building1/floor03/# 20K/day
All temperatures building1/+/+/sensor/temperature 20K/day
Room 12 control panel building1/floor03/room12/# 1K/day
All HVAC status building1/+/+/hvac/status 10K/day

Step 4: Calculate Topic Count

Rooms: 10 floors x 20 rooms = 200 rooms
Sensor topics: 200 rooms x 4 sensors = 800 topics
Actuator topics: 200 rooms x 3 actuators x 2 (command + status) = 1,200 topics
Total: ~2,000 unique topics

Result: The topic hierarchy building1/floor03/room12/sensor/temperature enables:

  • 5 subscription levels: Building, floor, room, device type, metric
  • Efficient filtering: Floor dashboard uses 1 subscription (building1/floor03/#) instead of 400
  • Scalable: Adding floor 11 requires no subscription changes for building-wide dashboards
  • Clear organization: Topic path is self-documenting

Key Insight: Invest time in topic hierarchy design before deployment. A well-designed hierarchy reduces subscription count by 10-100x and makes the system self-documenting. The pattern {location}/{sublocation}/.../{device}/{metric} works for most IoT applications. Avoid flat topics like sensor_floor3_room12_temp which cannot be filtered with wildcards.

Think of MQTT topics like a postal address system:

Postal System MQTT Topics
Country/State/City/Street home/floor1/bedroom/temperature
Send letter to address Publish message to topic
Forward all mail from ZIP code Subscribe with wildcard home/floor1/#

The + wildcard is like saying “any single word here” - home/+/temp means “any room’s temperature”

The # wildcard is like saying “everything from here down” - home/# means “all home data”

Golden Rule: You can only use wildcards when RECEIVING mail (subscribing), not when SENDING mail (publishing). You must send to a specific address!

Scenario: A retail chain has 50 stores, each with 20 IoT devices (door sensors, temperature monitors, occupancy detectors, POS terminals). Design an MQTT topic hierarchy that enables both store-level and chain-wide monitoring.

Requirements:

  • Store managers see only their store’s devices
  • Regional managers see 10 stores in their region
  • Corporate dashboard sees all stores
  • IT department manages devices by type across all stores

Solution: Three-level hierarchy

company/region/store/device-type/device-id/metric

Examples:
company/west/store-sf01/door/main-entrance/status
company/west/store-sf01/hvac/zone-1/temperature
company/east/store-ny15/pos/terminal-3/transaction

Subscription patterns: | Role | Pattern | Messages Received | |——|———|——————-| | Store SF01 manager | company/+/store-sf01/# | All SF01 devices (20 devices x 3 metrics = 60 topics) | | West region manager | company/west/# | All 10 western stores (200 devices total) | | Corporate dashboard | company/# | All 50 stores (1,000 devices) | | IT device management | company/+/+/hvac/# | All HVAC devices chain-wide (50 stores) | | Security team | company/+/+/door/# | All door sensors chain-wide (100 sensors) |

Why this works:

  • ACLs map naturally: Store manager gets read access to company/+/store-sf01/#
  • Adding new stores requires no code changes to subscriptions
  • Regional boundaries are explicit in topic structure
  • Device-type grouping enables maintenance team subscriptions
  • Total topics: 50 stores x 20 devices x 3 metrics = 3,000 topics (manageable)

Alternative rejected: Flat structure like store-sf01-door-main-entrance-status prevents wildcard filtering and forces subscribers to maintain explicit topic lists that break when stores are added.

34.5.1 Multi-Site Topic Count Calculator

Plan topic counts for multi-site deployments such as retail chains, campuses, or smart city districts.

Test your recall of MQTT architecture and topic hierarchy concepts before reviewing the worked examples.

34.6 Summary

This chapter covered MQTT’s fundamental architecture patterns:

  • Publish/Subscribe Pattern: MQTT decouples publishers from subscribers through a central broker, enabling many-to-many communication without direct connections between clients
  • Component Roles: Publishers send to topics, the broker routes based on subscriptions, subscribers receive matching messages
  • Topic Hierarchies: Use hierarchical naming (home/bedroom/temperature) to organize messages and enable efficient filtering
  • Wildcard Subscriptions: Single-level (+) matches one level, multi-level (#) matches zero or more levels - both are subscribe-only
  • Topic Design Best Practices: Use pattern {location}/{device_type}/{metric} for scalable systems that support efficient wildcard filtering

34.7 What’s Next

Continue exploring MQTT with these related chapters:

Chapter Focus Why Read It
MQTT QoS and Reliability Delivery guarantees and session management Understand how QoS 0, 1, and 2 interact with the topic hierarchy you designed here
MQTT Production Deployment Broker clustering, security, and scalability Apply topic-hierarchy ACL design to a real multi-broker production environment
MQTT Fundamentals Core pub/sub concepts and packet format Reinforce the wire-level mechanics behind the architecture patterns covered here
MQTT Topics and Wildcards Deep-dive topic naming and wildcard rules Extend your topic-design skills with advanced patterns and anti-patterns
CoAP Fundamentals and Architecture Request-response alternative to pub/sub Compare the hierarchical resource model of CoAP with MQTT’s topic hierarchy
AMQP Fundamentals Enterprise message queuing with exchanges Evaluate AMQP routing patterns as an alternative when broker-side filtering logic is needed