The high-load backend behind an OTT streaming platform
The distributed backend for Vectra's TV Smart — live TV, VOD and timeshift served across the EU, built as independent microservices on GCP.
- Stack
- Laravel · Go · Python · MySQL · Redis · Kafka · GCP
- Scale
- tens of thousands of concurrent play requests
- Workload
- live TV · VOD · timeshift, EU-wide
Live TV is the least forgiving workload in streaming
A VOD title can stall for a second and nobody notices; a live football match cannot. When an event kicks off, tens of thousands of viewers press play inside the same minute — and every one of them expects the stream to authorize, the guide to load, and package entitlements to resolve with no perceptible delay.
The backend has to absorb that spike without degrading, then settle back to baseline minutes later. A design that is comfortable at average load but folds at the peak is the wrong design — the peak is exactly the moment that matters.
Independent microservices, the right language on each path
The backend was decomposed into independent services — playback and entitlements, EPG, VOD catalog, recording (NPVR) and billing — each owning its own data and scaling on its own. Performance-critical paths, stream authorization and manifest resolution, were written in Go for throughput and predictable latency; Laravel and PHP carry the business logic and admin surfaces; Python powers the data-processing and integration jobs.
Services talk over REST for synchronous calls and Kafka for everything asynchronous. Playback events, recording jobs, entitlement changes and EPG updates all flow through event streams, so no service blocks waiting on another — a slow consumer downstream never stalls the play request in front of the viewer.
Redis in front, MySQL shielded from the burst
Redis fronts the hottest data — session state, EPG windows, entitlement lookups — so stream-authorization decisions never hit MySQL under peak load. Slow queries were profiled and reworked, indexing and connection pooling tuned, and read traffic separated from writes. Load balancing spreads requests across service replicas, and the caching layer absorbs the burst so origin services see a fraction of the raw volume.
The failure mode of a naive setup is a cascade: authorization falls through to the database, the database saturates, timeouts back up into the services, and the slowdown spreads until the whole play path degrades at once — precisely during the live event. Fronting the hot path with cache and keeping reads off the write path is what turns that cascade into stable latency during the spike.
A production backend at national scale, not a prototype
This is the live backend of a national operator's OTT platform, running across the EU — not a proof of concept that works in a demo and falls over in the field. It carries real subscribers, real billing and real live events, and it was built to hold latency steady at the exact moment a spike arrives.
The engineering that makes that possible is not specific to television. A decomposed service architecture, the right language on each path, event streams instead of blocking calls, and a caching layer that shields the database are the same tools any system needs when its traffic arrives in bursts rather than a steady flow.
See what this would look like in your operations.
30 minutes · we map your 3 best automation opportunities · no obligation