Part 1: Understanding what realtime means
We describe Ably as a realtime data delivery platform. But there is quite a bit of confusion around what ‘realtime’ actually means and whether this is any different from the web as we know it, but faster.
Is realtime a ‘thing’? Is it a trend? Is it an identifiable set of technologies or experiences? Could it even be a paradigm shift?!
In this two part article we will look first at what realtime means and Part 2 gives examples of realtime digital experiences now and what we can expect in the future.
The realtime web, or realtime data, is not Titanic sinking in real time…
If you want to watch the Titanic sinking in real time you can:
Titanic sinks in real time
It takes two hours and forty minutes. A chilling experience in a number of ways.
This is real time in as much as the time over which the event took place is not edited. Not cut down, nor elongated. This is the actual time, the *real* time, it took.
But clearly this took place in the past. It is not happening now, live.
For clarity how about we call this ‘real time’ as opposed to ‘realtime’?
Realtime = sub 100ms
Any realtime data infrastructure provider, Ably included, will sell with a promise of very low latency globally. Or at least they should do.
Data and messages cannot be delivered completely instantaneously of course. However, as a guide we would say:
Anything that can be delivered in under 100 milliseconds is ‘realtime’.
Of course there is a big difference between how fast something actually is versus how fast it is perceived to be. And indeed how fast something even needs to be to feel ‘realtime’.
Robert Miller’s research from 1968 found that response times of 100ms are perceived as instantaneous. Most of us can only react in around 250ms; the fastest-reacting humans get that down to around 120ms. Research shows that some live gaming experiences deteriorate above 50ms.
So aim for sub 100ms and you can reasonably safely call yourself realtime.
Realtime is live and synchronous
Unlike the realtime recreation of Titanic sinking, the realtime web, and the realtime data infrastructure that powers it, is about an experience that is happening live, now.
Whether that is live data, live scores or results, or a live interaction like chat or customer support, it is an open, bi-directional, synchronous, channel of communication.
Realtime is like a conversation you are having with someone in the present moment: you immediately get the information and either of you can talk at any time.
This is why when many people think of “realtime messaging” they think about chat apps. It is actually much more than that because realtime data can be just machine to machine but certainly chat apps do give us realtime feedback on what others in the conversation are doing:
And we can immediately see when messages have been sent, received or read:
Realtime is not request/response
Microsoft’s CEO Satya Nadella is talking about “conversations as a platform” being the next big thing. Indeed, a “paradigm shift”, like the graphical user interface, the web browser and the iPhone-driven adoption of the touch screen.
All the big players are at it… Google Now, Twitter Moments, Facebook Live, Snapchat Live Stories. Things are going realtime, live, now-y.
If there is an emerging new paradigm with realtime then it is because realtime does not rely on a request/response model.
Consider our conversation metaphor from the previous section. Email is not like that. With email you send an email and await a reply. It can happen quickly but it is not realtime. Letters are the same: you send (request) and await a response.
Almost every experience on the web currently is still request/response. You do something, typically a click or touch, in order to get something else to happen.
But that is changing.
Most social data streams and updates happen in realtime. You do not refresh (i.e. request) your app to see the latest; it is pushed to you in realtime. Like notifications of new tweets in Twitter:
Or realtime location tracking services that are part of an increasing number of apps. For example, in Uber, you can see your car on a map as it drives towards you in realtime. You do not need to keep requesting that information. It is data streamed within the app in realtime:
There are limitations in the ‘old’ paradigm of request/response:
- Data cannot be pushed to devices like it can with realtime
- Latencies are relatively high (i.e. it is slow) whereas realtime is near instantaneous
- State is not typically maintained between requests. This can be a real problem for some use cases. Actually most realtime systems are not able to maintain state either. <plug> But Ably can </plug>.
So perhaps we will come to expect that most experiences are realtime and that will change what we expect of user interfaces.
To get examples of realtime in action read part two of this article: