Ably ensures that messages are delivered to persistently connected subscribers on a channel in the order they were published on that channel by any other client when using one of our Realtime libraries.
For example, if you are publishing messages using a Realtime client library, the order in which subscribers receive those messages on that channel anywhere in the world will always be the same order that the messages were originally published. This guarantee is possible because every message sent on a realtime connection has a unique incrementing message serial.
Please note that in the following circumstances ordering may not be maintained:
- Publishing over REST
If you are publishing using a REST client library, we can still guarantee that the order in which we receive messages will be honoured for all subscribers. However you should be aware that if you are sending messages at a high rate and each message send is a separate REST request, then it is possible that a later HTTP request may reach Ably before a previous request due to variable network factors outside of our control. If ordering is important to you, we recommend you either rate limit your HTTP requests and batch messages together, or use our Realtime client library to publish messages.
- Disconnected client and server termination
As we support connection state recovery, even if a connection is lost and re-established, the order of messages replayed when reconnected will be sequential i.e. in order. However, there is a very rare situation one must consider when a client is disconnected whereby if the server that is maintaining a disconnected client's connection state is terminated or recycled at the time the connection state is being recovered, then it is plausible (but unlikely), that messages may be replayed out of order. This behaviour is by design to ensure that the backlog of messages held in the connection state do not hold up the new server from sending realtime messages to clients. If message ordering is required in all cases, we recommend you catch the connection disconnected event and either re-establish a new connection or manually re-order of incoming messages following disconnection.