MQTT GUIDE
3 min readMQTT Request-Response Pattern
The request-response pattern lets a requester get a reply over MQTT’s publish/subscribe transport. Made first-class in MQTT 5.0, the requester publishes with a Response Topic (where the reply should go) and Correlation Data (an ID to match the reply to the request); the responder publishes its answer to that topic, echoing the same Correlation Data.
MQTT is built around one-way publish/subscribe, but plenty of real interactions need a reply — “read this value”, “run this command, tell me the result”. MQTT 5.0 adds a first-class request-response pattern for exactly this, without leaving pub/sub behind.
How request-response works in MQTT 5.0
The requester publishes its request and attaches two properties: a Response Topic (where it wants the reply) and Correlation Data (an ID to match the reply to this request). The responder — a client subscribed to the request topic — does its work and publishes the answer to that Response Topic, echoing the same Correlation Data. The requester, subscribed to the Response Topic, receives it and matches it up.
Response Topic and Correlation Data
Before MQTT 5.0
The pattern was possible in MQTT 3.1.1, but you had to build it yourself — encode a reply topic and a correlation ID into the payload or the topic string by convention, and hope every client agreed on the format. MQTT 5.0 moves both into standard message properties, so libraries and brokers can support the pattern directly. It is one of the reasons to consider MQTT 5.0.
Request-response in TBMQ
TBMQ fully supports MQTT 5.0 and carries Response Topic, Correlation Data and User Properties through end to end, so request/response flows run over the same broker as the rest of your traffic. See the MQTT protocol guide for supported features.
Frequently asked questions
Can you do request-response in MQTT 3.1.1?
Yes, but by convention rather than protocol. The requester includes a reply topic and a correlation ID somewhere in the payload or topic, and the responder publishes there. MQTT 5.0 makes this first-class with the Response Topic and Correlation Data properties, so it no longer has to be baked into the payload.
What is Correlation Data?
An opaque value the requester attaches to a request so it can match the reply back to the original request. The responder copies it verbatim into the response. It matters when a client has several requests in flight on the same response topic.
What is the Response Topic?
The topic the requester wants the reply published to. The responder reads it from the request and publishes its answer there — so the requester controls where the response lands, and typically subscribes to that topic beforehand.
Is MQTT request-response synchronous?
No. It runs over pub/sub, so it is asynchronous: the requester publishes, then receives the reply as a separate incoming message on the response topic. There is no blocking call and no guarantee of a reply — design for timeouts.
How is this different from HTTP request/response?
HTTP ties the response to the same connection and blocks until it arrives. MQTT decouples the two through the broker: requester and responder never connect to each other, either can be offline at different moments, and one responder can serve many requesters over a long-lived connection.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.