Query Regarding Message Order with HiveMQ vs. AWS IoT MQTT

I’m currently utilizing AWS IoT MQTT to transmit small binary packet data at a frequency of one packet per second. However, I’ve encountered an issue where some packets are received out of order on the client side.

Before considering a migration or switch, I wanted to inquire:

  1. Are there known differences in how HiveMQ handles MQTT message ordering compared to AWS IoT MQTT that might address this issue?
  2. Have other users migrating from AWS IoT to HiveMQ observed improvements in maintaining message order, especially under high-frequency scenarios like mine?

Understanding this will greatly assist in my decision-making process.

Hi @qwert477 ,

It’s fantastic to hear that you’re interested in MQTT and the HiveMQ broker. Welcome to the HiveMQ Community! We’re thrilled to have you join us.

The MQTT specification does not inherently guarantee message ordering. Thus, it is advisable to consider incorporating a custom ordering key within the payload or the User Properties of the transmitted message. The subscribing client should then be responsible for extracting this key and orchestrating the sequencing of received messages accordingly.

This consideration arises from the potential for disruptions in the broker-client connection, which may lead to message retransmissions and, consequently, introduce duplicate messages and disrupt the intended order.

Interestingly, HiveMQ’s broker can provide an assurance of message order within a specific topic-to-client context when utilizing QoS 1 or QoS 2. In this scenario, retransmitted messages will consistently maintain their original order. For example, in a sequence of published messages numbered 1 through 5, should an interruption occur between messages 2 and 3, the broker will ensure the retransmitted messages follow the order of 3, 4, and 5, as opposed to alternative sequences like 4, 3, 5, or 5, 3, 4.

For applications necessitating strict adherence to message ordering, it may be imperative to introduce supplementary logical mechanisms within the client implementation.

I hope that helps.
Best regards,
Dasha from HiveMQ Team

1 Like