# OTT-schaalbaarheid: 100.000+ gelijktijdige livekijkers aankunnen

**Source:** https://vodlix.com/nl/blog/ott-platform-scalability  
**Summary:** Ontdek hoe OTT-platforms meer dan 100.000 gelijktijdige kijkers aankunnen met schaalbare CDN's, adaptieve streaming, veerkrachtige infrastructuur, monitoring en load testing.  
**Published:** 2026-08-11  
**Publisher:** Vodlix

---

Een livestream kan perfect draaien met 10.000 kijkers en tóch onderuitgaan wanneer er binnen een paar minuten 100.000 mensen bijkomen.

Dat is de echte uitdaging van **schaalbaarheid van OTT-platforms**.

Livesport, breaking news, concerten, productlanceringen, religieuze bijeenkomsten en grote entertainmentreleases kunnen plotselinge verkeerspieken veroorzaken die sterk verschillen van de normale streamingvraag. Het platform moet video ingesten, verwerken, autoriseren, distribueren en monitoren terwijl duizenden kijkers vrijwel gelijktijdig binnenkomen.

Het antwoord is niet simpelweg meer servers toevoegen. Een schaalbare OTT-architectuur moet het grootste deel van het afleverwerk naar de edge verplaatsen, de origin beschermen, adaptieve bitrate-streaming ondersteunen en genoeg redundantie hebben om storingen te overleven.

Deze gids legt uit wat er nodig is om een OTT-platform voor te bereiden op **100.000+ gelijktijdige kijkers** en wat streamingbedrijven zouden moeten testen vóór een groot live-evenement.

## Waarom zijn 100.000 gelijktijdige kijkers zo lastig? {#waarom-zijn-100-000-gelijktijdige-kijkers-zo-lastig}

Gelijktijdige kijkers zijn iets anders dan het totale aantal kijkers.

Een platform kan miljoenen geregistreerde gebruikers hebben terwijl slechts een klein deel op hetzelfde moment kijkt. Bij een groot evenement kunnen echter duizenden gebruikers vrijwel tegelijk binnenkomen.

Stel je bijvoorbeeld een platform voor dat normaal 15.000 gelijktijdige kijkers bedient. Een kampioenswedstrijd begint en 100.000 gebruikers proberen binnen enkele minuten te kijken.

Dat zet meerdere lagen onder druk:

- Video-ingest
- Encoding en transcoding
- Origin-infrastructuur
- CDN-aflevering
- Authenticatie
- DRM
- API's en databases
- Playerverzoeken
- Analytics
- Betaal- of rechtensystemen

Het belangrijkste principe is daarom eenvoudig:

**Laat het verkeer van 100.000 kijkers je origin niet bereiken alsof elke kijker een aparte videoverbinding is.**

Een CDN moet het grootste deel van de afleverlast opvangen. Video-CDN's brengen content dichter bij de kijker en verlagen de hoeveelheid verkeer die naar de origin moet terugkeren.

## De architectuur achter schaalbare livestreaming {#de-architectuur-achter-schaalbare-livestreaming}

Een OTT-architectuur met hoge gelijktijdigheid kun je zien als een pipeline:

**Livebron → Ingest → Encoding → Packaging → Origin → CDN → Player**

Elke laag heeft een andere verantwoordelijkheid.

### **1. Betrouwbare ingest**

De livefeed is het startpunt. Valt de invoer weg, dan redt geen enkele hoeveelheid CDN-capaciteit de stream nog.

Voor grote evenementen is het de moeite waard om redundante ingestpaden te overwegen. Referentiearchitecturen zoals de livestreamingoplossing van [AWS](https://aws.amazon.com/media/resources/live-streaming/) gebruiken een primaire en een secundaire invoer om de veerkracht te vergroten.

### **2. Adaptieve bitrate-encoding**

Eén stream met hoge bitrate is niet geschikt voor elke kijker.

De encoder moet meerdere kwaliteitsniveaus aanmaken, zodat de player daartussen kan schakelen op basis van de beschikbare bandbreedte en de prestaties van het apparaat.

Bijvoorbeeld:

| **Kwaliteit** | **Typisch gebruik** |
| --- | --- |
| 360p | Lage bandbreedte / mobiel |
| 480p | Basiskijken |
| 720p | HD-streaming |
| 1080p | Full HD |
| 4K | Premium / hoge bandbreedte |

De precieze bitrate-ladder moet worden bepaald op basis van de content, de apparaten, de codec en het doelpubliek.

Vodlix ondersteunt [adaptieve streaming met HLS en MPEG-DASH](https://vodlix.com/features/hls-mpeg-dash), zodat meerdere kwaliteitsvarianten kunnen worden geleverd op web, mobiel en tv.

### **3. CDN-first aflevering**

Het CDN is een van de belangrijkste onderdelen bij het opvangen van een gelijktijdigheidspiek.

In plaats van dat elke kijker videosegmenten telkens opnieuw bij de origin opvraagt, kunnen CDN-edgelocaties gecachete content dichter bij de gebruiker serveren.

Een referentiearchitectuur voor livestreaming van AWS plaatst een origin-/packaginglaag achter Amazon CloudFront, waarbij het CDN de stream naar de kijkers distribueert.

Bij een evenement met 100.000 kijkers is dat onderscheid cruciaal.

Je applicatieservers zouden vooral applicatielogica moeten afhandelen. Je CDN zou het zware werk van de videoaflevering moeten dragen.

## De origin mag niet het knelpunt worden {#de-origin-mag-niet-het-knelpunt-worden}

Een van de grootste fouten bij livestreaming is ontwerpen vanuit de aanname dat de origin gewoon meeschaalt met het aantal kijkers.

Stel je 100.000 kijkers voor die hetzelfde livesegment opvragen. Als die verzoeken telkens de origin bereiken, raakt de infrastructuur snel overbelast.

Daarom zijn cachingstrategie, origin shielding en efficiënte segmentaflevering zo belangrijk.

Livestreaming is extra veeleisend omdat manifests continu veranderen en segmenten snel achter elkaar binnenkomen. De architectuur moet dus worden ontworpen rond het aanvraagpatroon van livevideo, in plaats van het als gewoon webverkeer te behandelen.

Een bruikbare vuistregel:

**Schaal de distributielaag, niet alleen de applicatieservers.**

[Cloudflare](https://www.cloudflare.com/learning/video/what-is-a-video-cdn/) merkt eveneens op dat video-CDN's voorkomen dat de origin overbelast raakt en tegelijk de latency verlagen door content dichter bij de kijker te serveren.

## Bereid je voor op de piek, niet op het gemiddelde {#bereid-je-voor-op-de-piek-niet-op-het-gemiddelde}

Als je normale verkeer 20.000 gelijktijdige kijkers is, is infrastructuur voor precies 20.000 ontwerpen riskant.

Het getal dat telt is je **verwachte piekgelijktijdigheid plus een veiligheidsmarge**.

Denk aan een eenvoudig planningsmodel:

**Verwachte piek = 100.000 kijkers**

Behandel die 100.000 niet als het maximum dat je systeem nog net moet aankunnen, maar zorg voor extra capaciteit voor onverwachte vraag en infrastructuurstoringen.

Je capaciteitsplan zou rekening moeten houden met:

- Piek aan gelijktijdige kijkers
- Groeisnelheid van het kijkersaantal
- Gemiddelde videobitrate
- Aantal CDN-regio's
- Segmentduur
- Aantal kwaliteitsvarianten
- Authenticatieverzoeken
- API-verkeer
- Analyticsverkeer
- DRM-/licentieverzoeken
- Verwachte geografische verdeling van het verkeer

Ook de bandbreedtebehoefte verandert sterk met de bitrate.

Bijvoorbeeld, bij een gemiddeld afgeleverde bitrate van 5 Mbps:

**100.000 kijkers × 5 Mbps = 500 Gbps**

Daarom is het geen verstandige architectuur om dit verkeer rechtstreeks via applicatieservers of één origin te duwen.

## Authenticatie en DRM hebben hun eigen schaalbaarheidsplan nodig {#authenticatie-en-drm-hebben-hun-eigen-schaalbaarheidsplan-nodig}

Videoaflevering is maar één deel van het systeem.

Wanneer een groot evenement begint, kunnen kijkers tegelijkertijd:

1. De app openen.
2. Inloggen.
3. Hun abonnement laten controleren.
4. Afspeelautorisatie aanvragen.
5. DRM-licenties aanvragen.
6. De stream laden.
7. Analytics-events versturen.

Als al die verzoeken bij dezelfde backendservice terechtkomen, kan de applicatie omvallen terwijl het CDN perfect werkt.

Scheid de workloads waar dat kan.

Authenticatie, rechtencontroles, API's, DRM, analytics en videoaflevering zouden geen één grote afhankelijkheidsketen mogen vormen.

Bij premiumcontent moet ook de beveiliging actief blijven tijdens piekverkeer. Vodlix biedt beveiligingsfuncties voor livestreaming, contentcontroles en DRM-mogelijkheden voor meerdere platforms als onderdeel van zijn OTT-platform.

## Zet monitoring aan vóórdat het evenement begint {#zet-monitoring-aan-vóórdat-het-evenement-begint}

Schaalbaarheid bevestig je niet door naar de server-CPU te kijken als het evenement al begonnen is.

Je hebt realtime inzicht nodig in de volledige streamingpipeline.

Belangrijke metrics zijn onder meer:

- Gelijktijdige kijkers
- Afspeelstarts
- Opstarttijd
- Bufferingratio
- Videobitrate
- CDN-hitratio
- Verkeer naar de origin
- HTTP-foutpercentages
- Authenticatielatency
- Reactietijd van DRM
- Fouten bij segmentaflevering
- Rebufferingmomenten
- Prestaties per regio

Vodlix bevat realtime analytics en rapportage om video- en publieksprestaties te monitoren. Steeds vaker helpt [AI in streaming](/blog/ai-in-streaming) platforms om content te verrijken en toegankelijkheid op schaal te verbeteren.

Het doel is achteruitgang te signaleren **voordat kijkers erover beginnen te klagen**.

## Load testing is niet optioneel {#load-testing-is-niet-optioneel}

Als je 100.000 gelijktijdige kijkers verwacht, maak dan van het live-evenement niet je eerste schaalbaarheidstest.

Test vóór de livegang.

Een bruikbare testopbouw kan er zo uitzien:

| **Testfase** | **Doel** |
| --- | --- |
| 10.000 gebruikers | Basislijn valideren |
| 25.000 gebruikers | Vroege knelpunten opsporen |
| 50.000 gebruikers | Schaalgedrag testen |
| 75.000 gebruikers | Piekvoorbereiding valideren |
| 100.000+ gebruikers | Verwachte evenementcapaciteit testen |
| Storingstest | Redundantie en herstel verifiëren |

De test moet meer simuleren dan alleen video afspelen.

Test inloggolven, API-verzoeken, afspeelautorisatie, manifestverzoeken, CDN-aflevering, DRM, analytics en herstel na het uitvallen van componenten.

De waardevolste test is vaak die welke het knelpunt blootlegt waarvan je het bestaan niet kende.

## Wat OTT-bedrijven zouden moeten doen vóór een groot live-evenement {#wat-ott-bedrijven-zouden-moeten-doen-vóór-een-groot-live-evenement}

Een praktische checklist vooraf zou moeten bevatten:

**1. Bevestig de piekgelijktijdigheid.**  
Schat het verwachte aantal kijkers op basis van eerdere evenementen, registraties, marketingbereik en [historisch verkeer](/blog/state-of-ott-streaming).

**2. Valideer de CDN-capaciteit.**  
Controleer of je afleverarchitectuur de verwachte geografische spreiding en bandbreedtevraag aankan.

**3. Test de origin.**  
Zorg dat de origin-infrastructuur beschermd is tegen plotselinge stortvloeden van verzoeken.

**4. Test authenticatie en DRM.**  
Een schaalbare videopipeline is nutteloos als gebruikers geen afspeelautorisatie krijgen.

**5. Test meerdere bitrateprofielen.**  
Controleer of kijkers van kwaliteit kunnen wisselen zonder onderbrekingen in het afspelen.

**6. Voer een realistische load test uit.**  
Test verder dan de verwachte piek in plaats van te stoppen bij het streefgetal.

**7. Richt monitoring en alerts in.**  
Weet precies welke metric een escalatie in gang zet.

**8. Bereid een terugvaloptie voor.**  
Kritieke uitzendingen zouden waar mogelijk redundantie moeten hebben voor ingest, verwerking en aflevering.

## Hoe Vodlix schaalbare OTT-streaming ondersteunt {#hoe-vodlix-schaalbare-ott-streaming-ondersteunt}

Deze hele infrastructuur zelf bouwen kan aanzienlijke expertise vergen op het gebied van engineering, cloud, CDN, beveiliging, monitoring en operations.

Voor streamingbedrijven die willen lanceren zonder [de volledige OTT-stack](https://vodlix.com/features) vanaf nul te bouwen, biedt Vodlix een direct inzetbaar OTT-platform met [livestreaming](https://vodlix.com/features/stream-live-video-online), [VOD](https://vodlix.com/features/vod), tv-uitzendingen, CDN-integratie, adaptieve streaming, analytics, monetisatie en aflevering op meerdere platforms. Vodlix is een volledig [white-label OTT-platform](https://vodlix.com/features/white-label), zodat je onder je eigen merk kunt lanceren en groeien.

De livestreaminginfrastructuur van Vodlix maakt gebruik van toonaangevende CDN's en is ontworpen voor schaalbare live-aflevering. Het platform ondersteunt daarnaast HLS en MPEG-DASH, adaptieve bitrate-streaming, realtime analytics en livecontent op web, mobiel en [tv-apps](https://vodlix.com/features/tv-apps).

Voor bedrijven die zich voorbereiden op grote live-evenementen betekent dit dat de aandacht kan verschuiven van het los bouwen van elk infrastructuuronderdeel naar het beheren van content, publiek, monetisatie en kijkervaring.

## Tot slot {#tot-slot}

Meer dan 100.000 gelijktijdige kijkers aankunnen gaat niet over het vinden van één server die krachtig genoeg is voor 100.000 mensen.

Het is een architectuurvraagstuk.

Een schaalbaar OTT-platform scheidt videoaflevering van applicatieworkloads, gebruikt CDN-infrastructuur om content te distribueren, beschermt de origin, ondersteunt adaptieve bitrate-streaming, houdt authenticatie en DRM schaalbaar, monitort de kijkervaring in realtime en test piekomstandigheden vóór het evenement.

Het belangrijkste: schaalbaarheid hoort te worden ontworpen **vóórdat** de verkeerspiek arriveert.

Als je bedrijf grote live-evenementen verwacht, is bouwen voor het gemiddelde publiek niet genoeg. Bouw voor het moment waarop iedereen tegelijk op Afspelen drukt.

**Q: Wat is schaalbaarheid van een OTT-platform?**

Schaalbaarheid van een OTT-platform is het vermogen van een streamingdienst om toenemende aantallen kijkers, videoverzoeken, bandbreedtebehoeften en applicatieverkeer te verwerken zonder noemenswaardig prestatieverlies.

**Q: Hoe kan een OTT-platform 100.000 gelijktijdige kijkers aan?**

Een schaalbare architectuur combineert doorgaans CDN-aflevering, adaptieve bitrate-streaming, veerkrachtige origin-infrastructuur, schaalbare authenticatie, monitoring en uitgebreide load testing.

**Q: Waarom is een CDN belangrijk voor livestreaming?**

Een CDN brengt video dichter bij de kijker en verlaagt de hoeveelheid verkeer die rechtstreeks door de origin moet worden geserveerd, wat de schaalbaarheid en afspeelprestaties verbetert.

**Q: Verbetert adaptieve bitrate-streaming de schaalbaarheid?**

Het helpt bandbreedte beheersen en verbetert het afspelen, omdat elke kijker een kwaliteitsniveau krijgt dat past bij zijn netwerk en apparaat.

**Q: Wat moet er worden getest vóór een evenement met 100.000 kijkers?**

Test videoaflevering, CDN-prestaties, origin-belasting, authenticatie, DRM, API's, analytics, afspeelstart, buffering en herstel na storingen.

**Q: Hoeveel bandbreedte vraagt streaming met 100.000 gelijktijdige kijkers?**

Dat hangt af van de afgeleverde bitrate. Bij gemiddeld 5 Mbps per kijker komen 100.000 gelijktijdige kijkers neer op ongeveer 500 Gbps aan totale videodoorvoer.

**Q: Ondersteunt Vodlix livestreaming?**

Ja. Vodlix ondersteunt live-tv, live-evenementen, HLS- en MPEG-DASH-streaming, CDN-aflevering, adaptieve bitrate-streaming, analytics, monetisatie en aflevering op meerdere platforms.

**Q: Moeten OTT-platforms ontworpen worden voor gemiddeld verkeer of voor piekverkeer?**

Ze moeten worden ontworpen en getest voor het verwachte piekverkeer, met extra capaciteit en redundantie. Gemiddeld verkeer is geen betrouwbare maatstaf voor grote live-evenementen.

**Q: Waardoor vallen livestreamingplatforms uit tijdens verkeerspieken?**

Veelvoorkomende oorzaken zijn onvoldoende CDN-capaciteit, overbelaste origins, knelpunten bij authenticatie en DRM, slecht geteste API's, gebrekkige monitoring en te weinig redundantie.

**Q: Is load testing noodzakelijk voor live OTT-platforms?**

Ja. Load testing helpt knelpunten in de infrastructuur te vinden voordat een echt evenement een onverwachte gelijktijdigheidspiek veroorzaakt.
