The feature of idempotency is now available across all Ably client library SDKs. In practice, this eliminates the possibility of unintentional duplication, and gives developers assurance realtime messages will only ever be published once.
The engineering challenges associated with implementing this feature over a distributed realtime platform are not insignificant — read how our engineers ensured idempotency on the Ably platform in our deep-dive concepts content series.
What is idempotency? How does it help me?
An idempotent operation is one that, whether performed once or many times, always has the same effect.
Idempotent REST publishing assures published messages are only processed once, even if client or connectivity failures cause a publish to be reattempted. Idempotency further supports Ably’s commitment to data integrity by eliminating inconveniences that come about when subscribers are inadvertently sent duplicated messages. This gives additional reassurance to those providing ‘mission-critical’ realtime operations (payments systems, in-play bets and so on) where duplicated messages would have a strong negative impact on end-user experience.
Ably implements this feature by associating a unique identifier with each message. Once a message with a given ID is accepted, further attempts to publish with the same ID do not result in duplication. Ensuring this idempotent property is satisfied — in real time, across distributed systems — raises some significant technical challenges. Details of the technical challenges associated with idempotency — and how to overcome them — are covered in Ably Concepts section.
Implementing idempotency – how to get started
1. Read
1.1 client SDKs have been updated to support both the library-supplied and client-supplied ID use-cases. Read the documentation showing how to implement idempotency for your realtime messages.
2. Watch
Watch our video explaining how to implement idempotency with Ably:
3. Get started
There are two ways you can use idempotent publishing with our REST client libraries now. In this first instance, you can now provide a unique message ID when publishing ensuring any automatic retries by our SDK are idempotent, as well as any retries by your workers.
In the second instance, you can enable idempotent publishing for any automatic retries by our SDK (this may occur following a network fault for example) with the following new ClientOption.
Please note that in client library SDKs 1.2+, the ‘idempotentRestPublishing’ client option will be enabled by default, and thus all automatic retries by the client library will be guaranteed to be idempotent.
You can also view the changelog to keep track of all the recent updates. If you want to expand your realtime offering, do get in touch. Our tech teams will be happy to advise.
