How I Scaled a Voting Platform to 10M+ Users in 22 Days
InfluencerX scaled to 10M+ concurrent users using four architecture layers: Redis as the primary vote counter (atomic INCR + sorted sets), Laravel Queues for async MySQL audit logging, CDN-first static delivery, and autoscaling NGINX behind a GCP load balancer. Zero downtime, sub-second responses throughout.
When Exhibit Magazine launched InfluencerX — a voting platform for influencer competitions — we didn't have the luxury of a gradual rollout. The campaign went viral on day one. Within 22 days, we were handling 10 million concurrent users.
Here's every architecture decision that made it work.
What Was the Problem?
Millions of users submitting votes simultaneously. Each vote needs to be: - Counted accurately (no lost votes) - Processed fast (sub-second response times) - Verified (one vote per user per round) - Displayed on a real-time leaderboard
All of this on a budget that didn't include auto-scaling Kubernetes clusters or a dedicated SRE team. Just me, Laravel, and a handful of GCP instances.
How Did Redis Become the Source of Truth?
The first lesson: don't hit the database for every vote. Redis became the primary vote counter using atomic INCR operations. Vote counts lived in Redis hashes, keyed by contestant ID. Reads for the leaderboard came from Redis ZSET (sorted sets), which gave us O(log N) ranking queries.
MySQL became the audit log — votes were queued and batch-inserted every 30 seconds via Laravel Queue workers.
How Did Queue Architecture Eliminate Database Bottlenecks?
The API endpoint for voting did exactly three things: 1. Validate the request (rate limiting, auth check) 2. Push to Redis (atomic increment) 3. Dispatch a queued job (for MySQL audit log)
No database writes in the hot path. The response time was consistently under 100ms.
How Did CDN-First Architecture Reduce Origin Load?
Static assets, leaderboard snapshots (refreshed every 10 seconds), and contestant profiles were served from CDN edge nodes. The origin servers only handled vote submissions and real-time data.
How Did NGINX Autoscaling Handle Traffic Spikes?
We ran multiple NGINX instances behind a GCP load balancer with health checks. When CPU or connection count exceeded thresholds, new instances spun up automatically. The key was pre-warming — we kept 2x our expected baseline capacity running at all times during peak hours.
What Were the Results?
- 10M+ concurrent users handled
- Sub-second API response times throughout
- Zero downtime over the entire 22-day campaign
- MySQL audit logs confirmed 100% vote accuracy
The biggest lesson: you don't need expensive infrastructure to scale. You need the right architecture — put Redis in front, queue everything that isn't urgent, and let CDNs handle the static layer.