Why implementing message ordering is kind of a big deal?
Very recently, The Next Web published a story highlighting how Apple was possibly messing up the order of messages exchanged via its iMessage app. A lot of users are continuing to identify this discrepancy which is apparently a long pending bug to be solved by Apple. But why is it such a big deal? Isn’t message ordering supposed to be super straight-forward to implement? Let’s find out the actual deal with message ordering behind-the-hood, in this post.
First of all, let us be clear that rather than just textual messages like in the example above, I shall refer to any payload of data being sent or received as a ‘message’. Generally, for messages to make sense, they are supposed to be received in the same order as they were sent by the sender. When this does not happen, it is ought to create a lot of confusion and frustration among the users just as you can see in the screenshot above!
From a tech perspective, when using a synchronous request and response pattern, this is less of an issue as each subsequent message is sent only after receiving a response from the previously sent message. The complexity arises when considering asynchronous event based systems such as those implementing the Pub/Sub messaging pattern.
In such a system, a duplex socket connection is opened up between the subscriber and publisher mostly via a realtime platform. Publishers no longer need to wait for a response but continue sending messages for as long as the connection remains open. Such a functionality of not having to wait for responses naturally comes with great benefits, but whilst messages sent from publishers to the platform are ordered, the second half of this journey, i.e, message ordering from the realtime platform to a subscriber is rarely ensured.
Using such a platform rather than trying to implement the complete realtime architecture from scratch is always better as it separates the concerns and lets developers focus on their product with its key business logic without having to worry about complex things like continuity, ordering, latency and integrity of messages to be exchanged within their product. It’s rather easier to rely on services like this which are already being developed, tested and maintained by another group of developers whose focus is just that.
Ably is one such realtime platform that uniquely solves this issue in two ways:
A little background - in Ably, messages in it’s realtime library are exchanged through something called ‘channels’. These can be conceptually thought of as pipes to which data is published and received from.
- Ably has a stateful system design which means that every channel is conceptually a running process that maintains integrity and delivery of messages on that channel and in the particular region.
- These stateful channels issue an ‘increment-only’ serial number to each message that’s sent on the channel in that particular region, thus ensuring all the subscribers receive the messages in the exact order in which they were originally sent by the publishers.
Read more about how Ably makes sure your messages are delivered in the right order. Or, sign up on Ably and start building your own realtime apps for free!
Serious realtime apps require serious architecture with guarantees beneath them!
Thoughts? Claps?
