Real-time en live platformtechnologie: wat het kost om iets te bouwen dat werkt op evenementschaal

Er is een moment in ieder live-evenement waarbij alles tegelijk kan breken. Het scherm gaat aan, de presentator noemt de app, en binnen dertig seconden proberen tienduizenden mensen tegelijk in te loggen. Als je die piek niet hebt geanticipeerd op architectuurniveau, merk je dat direct.

Bij Livewall hebben we dit soort momenten meerdere keren gebouwd. Niet als oefening, maar in productie, voor uitzendingen met een nationaal publiek. Wat we geleerd hebben: evenementschaal is een andere discipline dan gewone webapplicatieontwikkeling. De technische patronen zijn anders. De risico's zijn anders. En de manier waarop je test is anders.

Wat 'real-time' technisch betekent

Real-time is een overgebruikt begrip. Technisch gezien zijn er drie gangbare benaderingen, elk met andere afwegingen.

WebSockets houden een permanente verbinding open tussen client en server. Dat is ideaal voor situaties waarbij de server actief data naar de gebruiker pusht, zoals live scoreborden, stemresultaten of chatfunctionaliteit. De prijs is dat elke open verbinding servercapaciteit vraagt. Bij 100.000 gebruikers tegelijk is dat een aanzienlijke last.

Server-Sent Events (SSE) zijn lichter: de server pusht updates naar de client via een eenrichtingskanaal. Goed voor situaties waarbij de gebruiker niet terugpraat, zoals een livefeed of een teller. Makkelijker te schalen dan WebSockets, maar minder flexibel.

Polling is de oudste aanpak: de client vraagt regelmatig aan de server of er nieuwe data is. Eenvoudig te implementeren, maar slecht schaalbaar bij hoge gebruikersaantallen. Bij een live-evenement met tienduizenden gebruikers die elk de halve seconde pollen, wordt dat snel een bottleneck.

De keuze hangt af van wat je bouwt. Bij een stemplatform waarbij gebruikers actief invoer geven en directe feedback verwachten, zijn WebSockets logisch. Bij een leaderboard dat elke paar seconden ververst, kan SSE meer dan voldoende zijn.

Het belastingsprofiel van een live evenement

Normale webapplicaties hebben een vrij voorspelbaar verkeersprofiel: gebruikers stromen door de dag heen in, pieken misschien tijdens lunchtijd of na kantooruren. Je kunt capaciteit geleidelijk opschalen.

Een live evenement werkt fundamenteel anders. Verkeerspieken zijn ogenblikkelijk, massaal en voorspelbaar op een exact moment. De uitzending begint, de call-to-action verschijnt op het scherm, en de piek is er al voordat je infrastructuur automatisch kan opschalen. Autoscaling reageert te traag voor die eerste dertig seconden.

Dit betekent dat je vooraf moet provisioneren voor de piek, niet voor het gemiddelde. En dat je weet hoe laat die piek komt, hoelang hij aanhoudt, en wanneer het verkeer daarna terugvalt. Die terugval is even relevant: je wilt geen resources betalen voor capaciteit die je na de uitzending niet meer nodig hebt.

Daarnaast heb je bij evenementplatforms te maken met gebruikers die allemaal tegelijk precies hetzelfde doen: inloggen, dezelfde pagina laden, dezelfde data opvragen. De homogeniteit van het verkeer is extremer dan bij gewone platformgebruikers.

Wat er kapot gaat onder evenementbelasting

In onze ervaring zijn er een handvol systemen die als eerste bezwijken wanneer het verkeer plotseling explodeert.

Databaseverbindingen. De meeste relationele databases hebben een limiet aan het aantal gelijktijdige verbindingen. Onder normale omstandigheden nooit een probleem. Maar wanneer duizenden gebruikers tegelijk queries sturen, loop je snel tegen die limiet aan. Een connection pooler (zoals PgBouncer voor PostgreSQL) is geen optimalisatie op evenementschaal, het is een vereiste.

Sessiestaat op de server. Als je applicatie sessiestaat opslaat op de server, wordt elke request afhankelijk van een specifieke serverinstantie. Dat maakt horizontaal schalen moeilijk. Bij evenementschaal wil je stateless applicaties waarbij sessiestaat in de client of in een gedeelde externe store (zoals Redis) zit.

Externe API's. Bijna elk modern platform integreert met diensten van derden: authenticatiediensten, betaalproviders, analyseplatforms. Onder piekbelasting worden deze integraties zwakke schakels. Als een externe API trager reageert of een rate limit bereikt, heeft dat directe impact op jouw gebruikerservaring. Je architectuur moet hiermee omgaan via timeouts, fallbacks en graceful degradation.

CDN-configuratie. Statische assets horen op een CDN, niet rechtstreeks van je servers geserveerd te worden. Dat klinkt vanzelfsprekend, maar we zien nog regelmatig platforms waarbij afbeeldingen of JavaScript-bestanden rechtstreeks van de origin server komen. Onder evenementbelasting voelt dat direct.

Hoe je voor evenementschaal ontwerpt

De architectuurkeuzes die het verschil maken, zijn niet ingewikkeld in concept. Ze vragen wel discipline om vroeg toe te passen, omdat ze later moeilijk zijn toe te voegen.

Stateless applicatielaag. Elke request moet door elke serverinstantie afgehandeld kunnen worden. Geen lokale state, geen sticky sessions. Dit maakt horizontaal schalen triviaal: je voegt instanties toe, ze werken direct mee.

Agressieve caching. Op evenementschaal is caching geen optimalisatie, het is een overlevingsstrategie. Gebruik meerdere cachelagen: een in-memory cache dicht bij de applicatie voor de snelste data, een gedistribueerde cache voor gedeelde staat, en een CDN voor alles wat de client direct kan ontvangen. Stel je de vraag bij elke data-aanvraag: moet dit echt vers zijn, of kan het een paar seconden oud zijn?

Graceful degradation. Bepaal van tevoren wat er gebeurt als een component uitvalt. Een externe API die niet reageert: toon gecachede data of een vriendelijke foutmelding. De real-time verbinding die wegvalt: val terug op polling. Een database die overbelast raakt: serve een statusmelding. Een platform dat gedeeltelijk werkt is beter dan een platform dat volledig vastloopt.

Wachtrijen voor schrijfoperaties. Elke actie waarbij gebruikers data schrijven, zoals een stem uitbrengen of een formulier indienen, kan via een wachtrij lopen. De gebruiker ziet direct een bevestiging; de daadwerkelijke verwerking volgt asynchroon. Dit beschermt de database tegen write-pieken.

Testen voordat het te laat is

Een van de meest gemaakte fouten bij evenementplatforms is dat load testing als laatste stap wordt gezien, of helemaal wordt overgeslagen. In onze ervaring is load testing een ontwerpactiviteit, niet een validatieactiviteit. Je test om te ontdekken waar de grenzen liggen, zodat je de architectuur kunt aanpassen voordat je live gaat.

Realistisch load-profiel. Test met een verkeersprofiel dat lijkt op het echte evenement: een rustige aanloop, een scherpe piek op een specifiek moment, en daarna een geleidelijke afname. Niet een gelijkmatige stroom over de tijd.

Elke externe afhankelijkheid meenemen. Load tests die alleen jouw applicatielaag testen en externe API's missen, geven een vals gevoel van veiligheid. Simuleer ook de traagte en fouten die externe diensten in de praktijk tonen.

Hersteltests. Test niet alleen of het platform de piek aankan, maar ook hoe het herstelt als een component tijdelijk uitvalt. Is sessiestaat bewaard? Missen gebruikers data? Hoe lang duurt herstel?

Voor het Eurovision-platform hebben we meerdere ronden load testing gedaan in de weken voor de uitzending. Elke ronde leverde inzichten op die de architectuur sterker maakten. Op de avond zelf waren we zeker over de grenzen, niet benieuwd ernaar.