2024 · Real-time voting platform · Exhibit Magazine India Pvt. Ltd. · Architect and lead engineer
InfluencerX
I architected and built a real-time voting platform for an influencer awards campaign: a React front end and services on Google Cloud Run behind a Google Cloud load balancer, Supabase for data, and two to three layers of caching in front of it, so the site stayed fast at peak without paying for idle servers.
1.6M+
users over the campaign
How this is measured
Total users of the voting platform over the campaign, not concurrent sessions. Window: 22-day campaign.
2,000+
concurrent users at peak
How this is measured
Users on the platform at the same moment, at the busiest point of the campaign.
99.99%
availability over the campaign
How this is measured
Availability over the campaign, from the Google Cloud load balancer's health checks: no failed check and no outage was seen during the campaign.
The constraint
Influencer competitions live or die on the voting window. Every vote is a write, the traffic arrives in waves driven by social posts, and everyone is watching the leaderboard.
Every vote had to be accepted and counted within a fixed campaign window of 22 days. Downtime or a lost vote would have been a public failure, and the budget ruled out simply buying more servers.
The architecture
- Cloud Run services behind a load balancer. The app runs as containers on Google Cloud Run, which adds instances as traffic grows; the Google Cloud load balancer spreads requests across them.
- Health checks decide where traffic goes. The load balancer checks every instance and sends requests only to healthy ones, so one bad instance never becomes an outage.
- Two to three layers of caching. Pages, leaderboards and repeated reads are answered from caches, so most requests never reach the database.
- Supabase for data. Votes and accounts live in Supabase (PostgreSQL), which only sees the requests the caches can't answer.
The diagram as text
Voters reach a Google Cloud load balancer, which sends requests only to healthy Cloud Run instances; caches answer most reads, and Supabase stores votes and accounts.
- Voters → CDN edge: reads
- Voters → Load balancer: votes
- Load balancer → Cloud Run: healthy instances
- Cloud Run → Cache: read
- Cloud Run → Supabase: write
Trade-offs
- Cached leaderboards are a few seconds behind the live count, in exchange for a site that stays fast during a voting wave.
- Managed services (Cloud Run, Supabase) instead of self-run servers: less control over the machines, far less to operate during a campaign.
- No Kubernetes: for one campaign with a known peak, Cloud Run's scaling was enough, without a cluster to run.
Results
- 1.6M+ users over the campaign, with 2,000+ at the same time at peak.
- Availability of 99.99%: the load balancer's health checks recorded no outage.
- The campaign ran its full 22 days on the platform.
- API responses stayed under <1 s at peak.
What I'd do again
- You don't need a cluster to handle a spike. Managed containers, a load balancer and caching did the work.
- Caching is what protects the database. Every read a cache answers is one the database never sees.
- Health checks are cheap insurance. Traffic only ever reached instances that were ready for it.
- Response time is the product during a vote. When the button is slow, people leave.
Stack
- React
- Google Cloud Run
- Google Cloud Load Balancing
- Supabase
- PostgreSQL
- CDN
- Google Cloud
Related services: Performance and Core Web Vitals audit, Launch-day readiness, Cloud, DevOps and cost.
Need something like this?
A short brief is enough to start. I’ll reply with questions, a suggested first step and when I could begin.