Message ordering guarantees in a cluster of brokers at failover

HiveMQ Client Library
1

Hello,

We are having a cluster of HiveMQ brokers with a load balancer in front of it and replica count > 1.
Our clients are using QoS 1 and persistent sessions. For one topic we need ordering guaranties. We have one publisher publishing on this topic, and one subscriber listening on it. This subscriber should see and acknowledge the messages in the order in which they have been published by the publisher. Duplicates of already acknowledged messages are okay.
Let’s assume for example, that the published publishes the messages in the order M1, M2, M3, M4, M5 on the same topic T. Then the subscriber should see them in that order.
To be more precise, let’s assume the subscriber has acknowledged M1 and M2 (via PUBACK) and now crashes while processing M3 before sending the PUBACK. When the client comes up again (without clearing its session), then it should receive M3 before receiving M4 and M5. It’s okay if it will receive M1 and/or M2 again before receiving M3, but in no case it should receive M4 or M5 before it has acknowledged M3.

  • Is this ordering assumption correct?
  • Does it hold even if the client fails?
  • Does it hold in a clustered setup?
  • Does it hold in a clustered setup even when the node to which the subscriber is connected fails?

I saw some conversation pointing into this direction like High Availability Cluster Support - HiveMQ Commercial Offerings - HiveMQ Support Forum, but there is also a blog post Understanding MQTT Message Ordering stating “Strict message ordering on an MQTT topic is not guaranteed in a clustered MQTT broker setup“. So, I am confused and some clarification would be helpful.

Thanks a lot in advance,
Sven

2

Hello @venhufezu

Welcome to HiveMQ Community Forum. Thanks a lot for the clear description of your use case.

For your scenario (one publisher, one subscriber, one topic, QoS 1, persistent session), your ordering assumption is correct:

  • If the subscriber has ACKed M1 and M2 and then crashes before ACKing M3, it will, after reconnecting with the same persistent session, receive M3 before any later messages (M4, M5).
  • Due to QoS 1 semantics, duplicates of already ACKed messages (like M1, M2) are possible, but later messages will not overtake an unacknowledged one.
  • This also holds in a HiveMQ cluster: HiveMQ replicates session and message state to other nodes before sending PUBACK, so even if the node with the subscriber fails, the client can reconnect to another node and continue its session with message ordering preserved, as long as the session replicas are still available.
  • Strict ordering is guaranteed only per publisher, per topic, per QoS level. If multiple publishers send to the same topic, a single global ordering across all publishers cannot be guaranteed.

Regarding the blog post that says “strict message ordering on an MQTT topic is not guaranteed in a clustered MQTT broker setup”:
that statement refers to the general clustered case (multiple publishers, possibly on different nodes, shared subscriptions, etc.), where the broker cannot enforce one global FIFO order for all messages on a topic. Your use case is a narrower, single‑publisher/single‑subscriber case, where the per‑publisher/per‑session ordering guarantees still apply.

We hope this helps.

Regards,
Sheetal from HiveMQ Support