At first glance, sports fans, news geeks, and pop culture enthusiasts seem largely dissimilar. Often, as a result, the apps that serve these groups are largely different – with a sports app comparing the stats of different athletes and a celebrity news app sharing video interviews and gossip.
But when these seemingly different users log on to these different apps, they’ll likely all expect the same thing: A fresh update published mere seconds after they opened the app.
The sports fan wants a score update; the news geek wants an update on a developing controversy; and the celebrity enthusiast wants an update on the latest gossip.
The value of these updates is in proportion to their instantaneousness, which makes building realtime update infrastructure high-stakes. As good as an app may otherwise be, if updates that are supposed to be realtime suffer even minor delays or integrity issues, then users will find a new app.
But despite a consensus around the value of realtime updates, many companies struggle to fulfill the promise of providing updates that feel instantaneous. As simple as an update might appear to the end-user, the infrastructure that supports the ability to continuously send realtime updates – reliably, at scale, and without error – is an enormous technical challenge.
In this article, we’ll explore why realtime updates matter and explain the technology that enables companies to provide updates at this speed and scale. We’ll then dive into what the best versions of this infrastructure look like, and walk through what it takes to build systems that can effectively provide realtime updates.
What are realtime updates and why do they matter?
Realtime updates are, in essence, data broadcasts that send updates from a backend to many different users all at once.
Realtime updates are most important in situations where an update’s recency is essential to its value. If we return to the example users above, we can imagine a few of many possible illustrative examples:
- If a sports fan is away from the television and can’t watch the game, they’ll want live score updates.
- If a news geek is keeping tabs on an international assembly, they’ll want to see discussion points in realtime, as they’re made.
Other cases extend beyond fans and geeks. In 2010, for example, a district in Massachusetts had an unexpectedly close election. One candidate was declared the winner by a single vote but a judge ruled that an initially discounted absentee ballot should have gone to the other candidate – resulting in a tie.
If a news app was providing updates on this election and others, you can imagine demand would have surged from across the state and all would have been waiting expectantly for realtime updates. Despite the increased and unexpected demand, these users would have all accepted the updates to feel instantaneous.
In each case, realtime updates are extremely valuable but even slightly delayed updates are almost meaningless. Learning about each decision and vote the moment they happen is exciting but learning about the results after everyone else has is boring.
Realtime updates, then, matter a lot to end-users – both in terms of the information in each update and the general ability for the updates to reliably arrive as soon as an event happens no matter how many other users are waiting on an update at the same time.
What do successful realtime updates look like?
Successful realtime updates are delivered as close to instantaneous as possible and are delivered reliably and at scale, despite expected and unexpected surges in demand.
Reliability, scalability, and integrity are what make realtime updates successful, but they're also the factors that make them them difficult to deliver. One of the first use cases for the Internet (when the Internet was little more than a connection between two computers) was the ability to send an email from one side of the room to the other.
In that sense, the core element of realtime updates is a solved problem. But the devil is in the details and decades after that first near-instant email was sent, companies are still struggling with the technical challenge of delivering realtime updates at scale.
Success across these elements is essential because even if the data stays the same – “The Bulls won!” or “Beyonce dropped a new album!” – the value of that data decays rapidly over time. From the inside, minor delays and rare integrity problems can seem forgivable but from the outside, with customers who badly want realtime updates and who have many apps to choose from, the standards are strict.
Realtime updates depend on three fundamentals
Sending a near-instant update from one point to another is not hard. But sending many updates at a massive scale to a multitude of users across the world is difficult.
The challenge, beyond the sheer intricacy of this work, is that the difficulty doesn’t grow linearly. This isn’t a situation where companies can build a V1 app that sends updates to 100 users and then add resources and servers as the user base grows.
When that user base expands and there ends up being ten times or one hundred times as many users distributed across the world all requesting updates at the same time, the challenge gets exponentially harder. Edge cases multiply, problems in one area create problems in another, and the typical approaches to scaling services don’t always work.
For example, as your user base grows, reliability will likely be a key priority. But reliability will be difficult considering the growth of users across the world. The 2022 World Cup Final, for example, had over 550 million viewers across the world and almost 17 million viewers from one channel in the United States – a country that didn’t have many soccer fans until relatively recently.
But if you’re providing realtime updates on the score of the game, even relatively new viewers from the United States will want reliable, rapid updates just the same.
You might solve that problem by adding servers to support larger amounts of demand but that solution creates another problem. If your system is replicating data across different data centers, how do you guarantee low latency? How do you synchronize message delivery? How can you ensure users don’t receive repeated updates even as your system copies the same updates into multiple data centers?
Latency, data integrity, and scalability aren’t new problems but handling them in a realtime context requires a strategy that suits the particular needs of a realtime system. The root problem isn’t any one of these elements working or not working. The root problem is meeting latency, data integrity, and scalability expectations all at once and without error.
Low latency
The value of low latency when delivering realtime updates can’t be overestimated. Even if there’s an election and as votes are tallied, the race gets closer and closer, and more and more users tune in, latency needs to remain low. Every user that opens the app needs to be able to get updates that feel instant – even in extreme circumstances.
In other contexts, companies assemble as many servers as necessary and use them to communicate directly with end-user devices. But if a company is providing realtime updates at scale, the standards are so strict and the space for compromise so small that the typical approach doesn’t work.
In those contexts, a difference of 100ms and 300ms is barely a problem for apps or their users but from the perspective of a user expecting realtime updates, latencies need to be 100ms or lower to feel “instantaneous” or “live.” Any slower and the update no longer feels realtime and the promise of the feature fails.
Maintaining data integrity
A realtime updates system that’s reliable at scale and consistently feels “live” despite unpredictable surges in users will still fail if the system can’t also maintain data integrity.
Data integrity refers to the challenge of ensuring each data point is accurate to its source, is only sent once, and follows other updates in the correct order.
Like latency, data integrity is make-or-break – especially for sports, media, and entertainment apps. A push notification that provides an instant update on a game-changing play is valuable for sports fans – a cause for delight. But if the update that follows that one repeats the information, then delighted users will become confused. And if a contradictory update arrives then the whole experience becomes confusing and the user might as well close the app.
Anything that mars data integrity – whether it’s an incorrect update or a series of updates delivered out of order – compromises the experience.
Operating at scale
Scalability, like low latency, is a value most companies care about. But for most companies, scalability is linear, meaning they can take their time adding resources to support 100 users one month, 1,000 the next month, and 10,000 the next month.
But in sports, media, and entertainment contexts, the demand for realtime updates scales up and down nonlinearly and unpredictably. Users of a news app, for example, will want realtime updates as an election approaches. Elections have a date that gives companies time to prepare for predicted demand but those same users will expect realtime updates even if a lawsuit against a major politician drops without warning.
Apps that promise realtime updates need to provide scalability for predicted demand and for unpredicted demand. The expectations of users remain the same: updates need to be realtime even as traffic spikes and concurrent user demand surges.
How sports, media, and entertainment companies can deliver realtime updates at scale
The promise to provide realtime updates is a big one. On the one hand, users find a lot of value in realtime updates and the apps that provide those updates will benefit from users’ resulting loyalty. On the other hand, offering and maintaining a realtime experience is high stakes because seemingly small problems can effectively disrupt the entire experience.
Companies often get ensnared trying to provide realtime updates because the types of problems are familiar – scalability, reliability, integrity – but the typical ways of solving them don’t work in a realtime context. People laugh about Twitter outages and complain about lag on Facebook or roll their eyes when the Amazon app crashes but if an app that promises realtime updates has even a small delay, then the experience will feel broken.
The higher-stakes technical challenge of realtime scalability, reliability, and integrity can’t be solved by turning a dial or by working more. The challenges get exponentially harder and the value collapses exponentially faster, meaning that meeting these expectations is harder than the sum of their parts and that when you fail to meet any individual expectation, the value to the end user collapses all the same.
All this makes building an in-house realtime infrastructure difficult. It’s not impossible, but it’s costly – in terms of money, effort, and time. Even companies ready to make a steep upfront investment can be surprised because the strict nature of a realtime experience means maintenance is perpetually necessary.
In our State of Serverless Websocket Infrastructure report, we found that it typically takes companies 10.2 person-months to build a realtime infrastructure project. If this were predictable, some companies might make the investment – but it isn't. 41% of respondents reported missing deadlines and 46% reported that costs grew so much that the project’s success was at risk.
With Ably, companies can deliver realtime experiences without needing to build the infrastructure themselves and without needing to worry about all the edge cases we’ve learned from. And that’s why businesses including Tennis Australia, Metra, and BlueJeans turn to our solutions.
To learn more, read about how you can use Ably’s APIs and SDKs to broadcast realtime data with low latency and high integrity.
This is the first in a series of four blog posts about the three fundamentals for building realtime updates in sports, media, and entertainment apps. In other posts, we look at why low latency, data integrity, and elasticity are so important when you're trying to deliver realtime updates to end users at scale.
