When a broker has messages to deliver faster than a slow gateway can accept them, something has to give, and without a limit the broker would simply keep pushing until the gateway drowns. MQTT version 5 adds a control for exactly this - Receive Maximum - which caps how many messages can be in flight and unacknowledged at once, forcing the sender to pause until the receiver catches up. This guide explains what Receive Maximum is, how the in-flight window creates backpressure, and why it protects a gateway on a constrained link from being flooded.
MQTT flow control in one line: Receive Maximum is an MQTT 5 setting where each side tells the other the maximum number of quality-of-service messages it is willing to have in flight and unacknowledged at any one time. Once that many are outstanding, the sender must stop and wait for acknowledgements before sending more, which provides backpressure and stops a fast broker from flooding a slow gateway link with messages it cannot keep up with.
Messages sent at a quality of service that guarantees delivery are not fire-and-forget; each one must be acknowledged, and until that acknowledgement comes back the message is in flight - sent but not yet confirmed. A sender can have several messages in flight at once, having sent them without yet hearing back on all of them, which keeps the pipe busy and throughput up. But every in-flight message is state the sender must hold and track, and there is a limit to how many it makes sense to have outstanding before things go wrong.
The danger without a limit is a fast sender overwhelming a slow receiver. If a broker has a backlog of messages for a gateway and simply sends them as fast as it can, but the gateway is on a thin, high-latency link and processes them slowly, the unacknowledged messages pile up. Memory fills with in-flight state on both sides, the slow link congests, and in the worst case the gateway falls over or the connection collapses under the load. The sender is producing faster than the receiver can consume, with nothing telling it to slow down.
Flow control is the general answer to that mismatch: a way for a slow consumer to signal a fast producer to ease off, matching the send rate to what the receiver can actually handle. In networking this is often achieved with a window - a cap on how much unacknowledged data may be outstanding - so the sender fills the window, then waits for acknowledgements to open it back up before sending more. Receive Maximum brings precisely this windowing idea to MQTT's quality-of-service message delivery.
Receive Maximum is a value each side announces when the connection is established: it is the number of quality-of-service messages that side is willing to have in flight and unacknowledged at any moment. In effect the receiver tells the sender, do not have more than this many outstanding to me at once. It defines the size of the in-flight window for that direction of the connection, and it is chosen by the party that will be receiving, because that is the party that knows its own capacity to keep up.
The mechanism creates backpressure naturally. The sender may send up to Receive Maximum messages, and then it must stop - it cannot send message number one more until an acknowledgement for an earlier one comes back and frees a slot in the window. As the receiver works through its backlog and acknowledges messages, slots open and the sender is allowed to send more. The pace of acknowledgements from the slow side therefore sets the pace of sending from the fast side, which is exactly the self-regulating behaviour flow control is meant to provide.
This keeps both ends bounded and stable. The sender never holds more than a fixed number of unacknowledged messages, so its memory for in-flight state is capped. The slow link never has more than a window's worth of messages pushed onto it before the sender pauses, so it does not congest under an unbounded flood. And the receiver dictates the limit that suits it, so a constrained gateway can set a small window and protect itself, while a capable one can set a larger window to allow more throughput. The single number tunes the trade-off between throughput and protection.
Field telemetry is a natural setting for this kind of backpressure, because the two ends of an MQTT connection are so unevenly matched. A cloud broker is fast and well-resourced; a remote gateway sits on a slow cellular or radio link and has limited memory and processing. When commands, configuration, or a burst of queued messages need to flow down to the gateway, the broker could easily outpace it. Receive Maximum lets the gateway declare a modest in-flight window so the broker sends at a rate the gateway can actually absorb, rather than flooding it and risking a dropped connection.
The benefit shows most clearly around recovery and bursts. After a gateway reconnects and the broker has messages queued for it, the temptation for the broker is to dump the whole backlog at once. On a thin link that dump can congest the connection and knock the gateway over just as it is coming back. With a sensible Receive Maximum, the broker feeds the backlog through the window at the gateway's pace, so the catch-up proceeds smoothly and completes rather than causing a second failure. The flow control turns a risky flood into a controlled drain.
For a cloud SCADA platform such as Merobix, this MQTT-level flow control complements the other mechanisms that keep field links healthy. It sits below application concerns and above the raw link, ensuring that no matter how much the platform has to send a gateway, it never sends faster than the gateway can acknowledge. That protects both ends across the flaky, low-bandwidth connections field sites depend on, keeping message delivery reliable and connections stable even when a slow gateway and a fast cloud have very different appetites for how quickly messages should move.
It limits the number of quality-of-service messages that can be in flight and unacknowledged at once in one direction of the connection. Each side announces its own value when connecting, and once that many messages are outstanding the sender must wait for acknowledgements before sending more. It does not limit fire-and-forget messages that require no acknowledgement; it applies to the delivery-guaranteed quality-of-service levels.
By capping the in-flight window, it forces the sender to stop once it has that many unacknowledged messages outstanding and wait for the receiver to acknowledge some before sending more. Because the receiver only acknowledges as fast as it can process, the pace of acknowledgements from the slow side controls the send rate of the fast side. That self-regulating pause-and-resume behaviour is the backpressure that stops a fast broker from flooding a slow gateway.
Because the broker it connects to is typically far faster and better-resourced, and without a limit it could push messages, especially a queued backlog after reconnection, faster than the gateway can accept them over its thin link. That can fill memory, congest the link, and collapse the connection just as the gateway recovers. Receive Maximum lets the gateway declare a window sized to its capacity so the broker feeds it at a manageable pace instead of flooding it.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.