Real-time and live platform tech: what it takes to build something that works at event scale

There is a moment in every live event where everything can break at once. The screen lights up, the presenter names the app, and within thirty seconds tens of thousands of people are trying to log in simultaneously. If you have not anticipated that spike at the architecture level, you feel it immediately.

At Livewall we have built these moments multiple times. Not as exercises, but in production, for live broadcasts with national audiences. What we have learned: event scale is a different discipline from standard web application development. The technical patterns are different. The risks are different. And the way you test is different.

What 'real-time' actually means technically

Real-time is an overused term. Technically, there are three common approaches, each with different tradeoffs.

WebSockets maintain a persistent connection between client and server. That is ideal for situations where the server actively pushes data to the user, such as live scoreboards, voting results, or chat. The cost is that every open connection consumes server capacity. With 100,000 simultaneous users, that is a significant load.

Server-Sent Events (SSE) are lighter: the server pushes updates to the client via a one-way channel. Well suited for situations where the user is not sending data back, such as a live feed or a counter. Easier to scale than WebSockets, but less flexible.

Polling is the oldest approach: the client regularly asks the server whether new data is available. Simple to implement, but it scales poorly at high user counts. With tens of thousands of users each polling every half-second during a live event, you hit bottlenecks fast.

The right choice depends on what you are building. For a voting platform where users actively submit input and expect immediate feedback, WebSockets make sense. For a leaderboard that refreshes every few seconds, SSE may be more than sufficient.

The load profile of a live event

Normal web applications have fairly predictable traffic profiles: users arrive throughout the day, with modest peaks around lunch or after business hours. You can scale capacity gradually.

A live event works fundamentally differently. Traffic spikes are instant, massive, and tied to a precise moment. The broadcast begins, the call to action appears on screen, and the spike arrives before your infrastructure can autoscale. Autoscaling responds too slowly for the first thirty seconds.

This means you must provision for the peak in advance, not for the average. And you need to know exactly when that peak arrives, how long it lasts, and when traffic drops off afterwards. That drop-off matters too: you do not want to keep paying for capacity you no longer need once the broadcast ends.

Event platforms also face a particular challenge: all users are doing exactly the same thing at the same time. They log in, load the same page, request the same data. The homogeneity of traffic is far more extreme than with typical platform usage.

What breaks under event-scale load

In our experience, a handful of systems tend to fail first when traffic explodes suddenly.

Database connections. Most relational databases have a hard limit on the number of simultaneous connections. Under normal conditions, this is never a problem. But when thousands of users fire queries at the same moment, you hit that limit quickly. A connection pooler such as PgBouncer for PostgreSQL is not an optimisation at event scale, it is a requirement.

Server-side session state. If your application stores session state on the server, every request becomes dependent on a specific server instance. That makes horizontal scaling difficult. At event scale you want stateless applications where session state lives in the client or in a shared external store such as Redis.

Third-party APIs. Almost every modern platform integrates with external services: authentication providers, payment processors, analytics platforms. Under peak load these integrations become weak links. If an external API slows down or hits a rate limit, it directly affects your user experience. Your architecture must handle this through timeouts, fallbacks, and graceful degradation.

CDN configuration. Static assets belong on a CDN, not served directly from your application servers. This sounds obvious, but we still regularly encounter platforms where images or JavaScript files are served from the origin server. Under event-scale load, that shows immediately.

How to architect for event scale

The architecture choices that make the difference are not complicated in concept. They do require discipline to apply early, because they are difficult to retrofit later.

Stateless application layer. Every request must be handleable by any server instance. No local state, no sticky sessions. This makes horizontal scaling trivial: add instances and they work immediately.

Aggressive caching. At event scale, caching is not an optimisation, it is a survival strategy. Use multiple cache layers: an in-memory cache close to the application for the fastest data, a distributed cache for shared state, and a CDN for everything the client can receive directly. Ask yourself with every data request: does this actually need to be fresh, or can it be a few seconds old?

Graceful degradation. Decide in advance what happens when a component fails. An external API that does not respond: show cached data or a friendly error message. A real-time connection that drops: fall back to polling. A database under strain: serve a status message. A platform that works partially is far better than one that locks up entirely.

Write queues. Every action where users write data, such as submitting a vote or completing a form, can go through a queue. The user sees an immediate confirmation; the actual processing follows asynchronously. This protects the database from write spikes.

Testing before it is too late

One of the most common mistakes with event platforms is treating load testing as the final step, or skipping it entirely. In our experience, load testing is a design activity, not a validation activity. You test to discover where the limits are so you can adjust the architecture before you go live.

Realistic load profile. Test with a traffic profile that resembles the actual event: a quiet build-up, a sharp spike at a specific moment, and then a gradual decline. Not a steady stream spread evenly over time.

Include every external dependency. Load tests that only exercise your application layer and ignore external APIs give a false sense of security. Simulate the latency and errors that external services produce in practice.

Recovery tests. Test not only whether the platform can handle the peak, but also how it recovers when a component temporarily fails. Is session state preserved? Do users lose data? How long does recovery take?

For the Eurovision platform, we ran multiple rounds of load testing in the weeks before the broadcast. Each round produced insights that made the architecture stronger. On the night itself, we knew the limits. We were not guessing at them.