High-performance, cloud-based voting platform
A high-performance, cloud-based voting platform built for Channel 4's interactive talent show The Singer Takes It All, handling up to 300,000 concurrent users securely on AWS.
Overview
The Singer Takes It All was a Channel 4 talent show, broadcast in August 2014, that combined live television with audience participation through a mobile app. Contestants, known on the show as hopefuls, uploaded karaoke-style video performances. Viewers voted each one ‘Hit’ or ‘Miss’ in the app, and those votes decided who made it onto the live broadcast.
The stakes were real. Votes determined who advanced and who won prizes on air, and the system behind them had to stay responsive under serious load.
up to 300,000 concurrent users at peak times.
Staying responsive at that peak drove the engineering throughout.
I led backend development. The mobile apps and the broadcast side were built by other teams, and my work covered the web API the apps voted through, the AWS infrastructure behind it, and the internal tools used in production. Those tools included an admin system for production staff, showing voting results, leaderboards and submissions in real time, and a moderation workflow so every uploaded video was reviewed before appearing publicly.
Architecture
The backend was built with ASP.NET Web API (C#), backed by a MySQL database holding users, votes and contest content. It ran on AWS EC2 instances behind an Elastic Load Balancer, scaling horizontally by adding web servers, with capacity increased ahead of each live episode.
Reads and writes had very different shapes. A vote had to reach the database quickly and safely, while leaderboards and top-contestant lists were read constantly by everyone. Those were pre-exported as JSON and cached on Amazon S3, so the heaviest read traffic never touched the database.
With several teams consuming the API, it shipped with interactive Swagger (OpenAPI) documentation, letting the app developers explore and test endpoints directly while everything was built in parallel.
Secure and fair voting
Voting required an authenticated user. Login used OAuth2 via Facebook or Twitter, each session was issued a short-lived bearer token, every call ran over HTTPS, and tokens could be revoked if abuse was detected. That prevented spam and duplicate voting.
Fairness needed engineering as much as security did. Contestant videos were served in random order, using random numbers assigned to each entry with seeds refreshed frequently, so every hopeful received an even share of exposure and votes.
Load testing
The defining challenge was the traffic surge around each live broadcast. To prepare, I built a custom load-testing harness, a substantial piece of software in its own right, which simulated thousands of concurrent users running realistic sessions of logging in, watching and voting.
The harness surfaced bottlenecks well before the first show. Database indices were tuned, the slowest SQL queries rewritten, critical operations moved into stored procedures, and asynchronous C# patterns used so requests could be handled in parallel. At this scale, small inefficiencies turn into bottlenecks, and finding them in a test run is far cheaper than finding them on air.
Outcome
The platform ran across the full series without downtime or slowdowns. Viewers uploaded around 9,500 video performances and cast over 21 million votes through the system.
The project won Best Multiplatform Project and Best App at the 2015 Broadcast Digital Awards, and was nominated for Digital Creativity at the BAFTA Television Craft Awards.
Delivery
I was responsible for the web API, the database design and optimisation, the load-testing harness, and the internal admin and moderation tools, working alongside the teams building the mobile apps and the show itself. The lessons in concurrency, caching and realistic load testing have carried into plenty of work since.