· 4 min read
How a voting platform held up through a 22-day campaign
The architecture behind the InfluencerX voting platform: Cloud Run behind a load balancer with health checks, layered caching and Supabase.
When Exhibit Magazine launched InfluencerX, a voting platform for influencer competitions, there was no gradual rollout. Voting opened, the links went out on social media, and the traffic came in waves. Over the 22 days of the campaign, the platform served more than 1.6 million users, with more than 2,000 of them on the site at the same moment at peak.
Here are the architecture decisions that made it work.
What was the problem?
Every vote is a write, and the traffic arrives in bursts whenever a contestant posts. Each vote had to be:
- Accepted and counted, with none lost
- Answered fast, in under a second even at peak
- Reflected on a leaderboard everyone was watching
And the budget ruled out simply buying more servers than we needed.
Why managed containers instead of a cluster?
The app, a React front end with its API, ran as containers on Google Cloud Run. Cloud Run adds instances as requests grow and removes them when traffic falls, so the platform paid for the peak only while the peak lasted.
We didn't use Kubernetes. For one campaign with a known shape, Cloud Run's scaling was enough, and there was no cluster to build, patch or watch.
How did the load balancer keep the site up?
A Google Cloud load balancer sat in front of the Cloud Run services and spread requests across the instances. Its health checks tested every instance continuously and sent traffic only to the healthy ones. If an instance struggled, it simply stopped receiving requests.
Across the campaign, the health checks recorded no outage.
How did caching protect the database?
Votes and accounts lived in Supabase, on PostgreSQL. The database is the one part that can't simply be multiplied, so the design kept most requests away from it.
Two to three layers of caching sat between visitors and the database: cached pages at the edge, and cached leaderboards and repeated reads in front of the data. Most requests were answered from a cache, and the database only saw the work that had to reach it, above all the votes themselves.
The trade-off: a cached leaderboard is a few seconds behind the live count. During a voting wave, a site that stays fast matters more than a leaderboard that is instant.
What were the results?
- More than 1.6 million users over the 22-day campaign
- More than 2,000 concurrent users at peak
- API responses under 1 second at peak
- 99.99% availability, with no outage seen by the load balancer's health checks
What would I tell someone building the same thing?
You don't need expensive infrastructure to survive a spike. Managed containers that scale on their own, a load balancer that only trusts healthy instances, and caching that keeps reads away from the database did most of the work. Response time is the product during a vote: when the button is slow, people leave.