The global increase of realtime data is spurred on by the steady rise of user demand for realtime digital experiences - from virtual events, news, and financial information to IoT devices. The Ably platform has been providing realtime infrastructure for over 5 years now, and we’ve seen, and helped, the demand increase first-hand. A few years ago, our customers only had realtime requirements for one or two specific features, usually around firing updates and notifications. Over time, their applications for realtime increased and diversified, spanning over entire platforms and services. Our feature development adjusted to satisfy the rising user demands.
Demand for message history leads to Channel Rewind
Initially, the core use case for most of our clients was to simply receive messages as they occur in realtime. In case clients disconnected temporarily, a 60-120 sec message buffer stored on our servers and returned via a History API request was enough to ensure they would receive the messages once they were back on the network.
But as use cases diversified, many users needed to access messages from a longer time span. For example, a public chat in a multiplayer game needs to provide messages from the last 5 minutes before a player joins, so they have more context about the in-game action. To provide for such use cases Ably allows persisting all the messages on a channel for up to 72 hours - as a feature that can be turned on and off.
Messages persisted for up to 72 hours were initially also returned via the History API, but the API did add some additional latency and complexity, especially for users who were not using the Ably Client Library SDKs. To solve this, we developed Channel Rewind, which allows users to pass a parameter along with a connection request to specify that they want to see previous messages upon connection. The client receives the realtime events as if they connected up to 100 messages earlier, meaning fewer API calls, lower latency, and lower bandwidth usage.
The need for State Persistence
Our users love the ability to attach to a channel, get the last state, and then subscribe to updates from that point forward via Channel Rewind. In a way, this feature makes Ably act a bit like a realtime database - you can connect and get the most recent updates, like you’d get them from a database, and then get updates in real time. Channel Rewind also fits nicely with Message Delta Compression, which saves bandwidth by sending subscribers only the changes from the previous message each time there’s an update.
However, there was yet another subset of use cases to consider. In distributed systems, you often need to model state. State can be:
- sporadically updated; often with temporal persistence requirements - such as a system configuration
- periodically updated, such as sensor readings or the position of a vehicle
- a cached value that only updates when changed, such as an e-commerce shopping cart
When it came to use cases that concern state, message persistence had two shortfalls: it was typically limited to the last 72 hours, and storing all messages on a channel when only the last message was needed was wasteful and costly. Our solution was to develop State Persistence.
State persistence allows users to persist the last message on the channel beyond typical Rewind and History API retention periods, for up to 1 year. To store the last published message on a channel for 365 days you first need to enable Persist last message as a channel namespace attribute. Then, you can retrieve the last message on the channel using either Channel Rewind or the History API.
Where State Persistence comes in very handy
State Persistence can save you from building extra functionality into your servers, and it can help you enable your serverless architecture.
Imagine you own an eCommerce store. Customers often abandon their shopping cart and close the store window, only to return to your site days, sometimes weeks later. When they return, they expect to find their shopping cart in the same state they left it, so they can easily complete the transaction.
The state of the shopping basket will be stored on your backend server, but you don’t want to query it and overload your server until the end-user actually does something. It’s more efficient to keep the state of the shopping basket as a message on an Ably channel, which is loaded as soon as the person connects. The last state of their shopping cart will be loaded via Ably, away from your backend servers, without even requiring them to create an account.
Or, say you are running lots of serverless functions, and their configuration is managed via another serverless function. To change your configuration dynamically, the manager function queries the last message on the Ably channel. When you want to change your configuration, you simply change the message you’re sending on the channel. As your serverless function starts running, you can build up elaborate state-based functionality, which can be changed anytime you like.
With state persistence, Ably allows you to model for a state that is sporadically updated and has temporal persistence requirements, but with the flexibility of a real-live data stream. If you’d like to give State Persistence a go, you could try it out using the free data sources on the Ably Hub as messages, for example, the weather data.
