A lot of IoT architecture ends at the broker in diagrams.
Real systems rarely do.
Once an MQTT message reaches a subscriber, the event often starts another journey. It may be transformed, stored, forwarded to an API, added to a data platform, used to trigger a workflow or sent to a customer's system.
MQTT has done its part.
Now somebody else owns the problem.
The consumer becomes a producer
Consider:
Device → MQTT → Integration service → Customer API
The integration service is an MQTT consumer.
But the moment it needs to send the event to the Customer API, it becomes a producer in a new delivery relationship.
It now has to deal with:
- API downtime
- timeouts
- 429 rate limits
- expired credentials
- payload rejection
- duplicate resend
- retry scheduling
Those problems are outside MQTT's responsibility.
The integration service can implement all of them itself.
Many do.
A subscriber can become a queue without meaning to
The simple version looks like this:
- subscribe to topic
- receive message
- call API
Then the API becomes unavailable.
What happens to the MQTT message?
If the consumer blocks until the API returns, throughput and broker behaviour may suffer.
If it acknowledges the MQTT side first and keeps the event in memory, a process restart can lose it.
If it writes the event to a local database before acknowledging, it has created a durable delivery queue.
Again, none of this is wrong.
The important point is that a new reliability system now exists after MQTT.
Keep the boundaries independent
There is a strong architectural reason not to stretch one protocol across every problem.
MQTT may be ideal for device-to-broker communication.
HTTP may be the only interface offered by the downstream SaaS system.
The local application should not have to replace MQTT simply because the external system speaks HTTP.
Likewise, the external destination should not need to understand MQTT simply because that is how the data arrived locally.
A delivery layer between the two can preserve those boundaries:
Device → MQTT → delivery layer → HTTP destination
MQTT remains MQTT.
The external API remains an API.
The delivery layer owns the translation in reliability semantics between them.
Failure types start to matter
MQTT's QoS model is about message delivery.
An HTTP destination introduces richer application responses.
A 503 usually suggests a transient service problem.
A 429 explicitly asks the sender to slow down.
A 401 may require new credentials rather than another identical retry.
A 422 can indicate that the same payload will continue to be rejected no matter how long the sender waits.
Treating all of these as “delivery failed, retry” is crude.
The farther an IoT event travels into application integrations, the more useful it becomes to understand *why* delivery failed rather than only that it failed.
This is where operational visibility matters
If an event stops after MQTT, somebody eventually has to investigate.
The useful questions are:
Did MQTT receive it?
Did the local consumer accept it?
Was it persisted?
Did cloud ingestion receive it?
How many destination attempts were made?
What did the destination return?
Can the event be replayed safely?
Without a shared event identity, those questions often require correlating logs across several systems.
With stable identity and explicit custody boundaries, the same event can be followed through the path.
Not every path needs another platform
For a small installation with a reliable downstream API, a simple MQTT consumer making direct HTTP calls can be perfectly good architecture.
Adding queues, databases and operational tooling “just in case” is not automatically better.
The threshold changes when failures have operational cost.
If the customer expects every event to arrive, if outages can last hours, if duplicates have consequences, or if support needs to explain exactly what happened to one specific event, the direct bridge begins to carry more responsibility.
That responsibility exists whether you call it infrastructure or application code.
MQTT is often the beginning, not the end
MQTT is very good at moving messages through the part of the architecture it controls.
The mistake is expecting the rest of the system to inherit those guarantees automatically.
Once the event leaves MQTT, define the next boundary just as clearly:
Who owns it?
What does success mean?
Where is it persisted?
What happens when the destination is unavailable?
Can the same logical event be sent again safely?
Those questions connect MQTT to the broader subject of this series: reliable delivery from the point where an event happens until the system that needs it has actually accepted it.