Request-response pattern
MQTT's publish-subscribe model delivers messages asynchronously with no built-in way to confirm a specific client received and acted on a message. The request-response pattern, an MQTT 5.0 feature supported by IoT Platform, adds a lightweight mechanism for correlated, bidirectional messaging — letting devices and servers exchange requests and confirmed responses over MQTT.
Overview
MQTT's publish-subscribe model fully decouples publishers from subscribers, which works well for fire-and-forget telemetry. However, some IoT scenarios require a response — for example, when a server controls a device switch, or a device retrieves data from a server. The request-response pattern extends MQTT 5.0 to support these interactions without abandoning the underlying pub-sub model.
How it works
Unlike HTTP, MQTT 5.0 implements the request-response pattern asynchronously, building on the publish-subscribe model. The requester attaches two MQTT 5.0 properties to the request message:
Response topic (ResponseTopic): the topic to which the responder publishes the response message.
Correlation data (CorrelationData): binary data carried in the request that the responder echoes back unchanged, letting the requester match each response to its original request.
The following flowchart shows the full communication process.
For multiple concurrent requests, include a unique request ID in the correlation data so each response maps to the correct request.
For real-time remote control, IoT Platform also provides the RRPC feature, which returns synchronous results.
A Quality of Service (QoS) 1 message guarantees delivery only to IoT Platform, not to the subscribing client. To confirm that the subscriber received and processed the message, use the request-response pattern.
Use cases
Device requests data from the server
A device that needs to fetch data from a server — for example, a smart cooking machine downloading recipes from the cloud — can use the request-response pattern. The server processes the request and publishes the response to the response topic without tracking which device sent which request, simplifying server-side development.
Device side: functions like a remote procedure call. Include correlation data to link each response back to its request.
Server side: process the request and publish the response to the response topic. No per-device response tracking needed.
Server remotely controls a device
When a server needs to control a device and confirm the action — for example, sending an "open" command to an electronic lock — the request-response pattern provides the necessary feedback loop. Include authentication data in the correlation data to authenticate the device during the exchange.
