Case 01 · arena · 2025
InfluencerX
A voting platform that stayed fast for all 22 days of a campaign.
The brief behind 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.
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. It was a high-traffic voting platform with a known peak and a fixed campaign window, built to stay fast without paying for idle servers.
What constrained the work
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.
How InfluencerX is built
- 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.
Trade-offs and why
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.
What changed, measured
- users over the campaign
- 1.6M+
- concurrent users at peak
- 2,000+
- availability over the campaign
- 99.99%
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.
Lessons from InfluencerX
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.
Technologies used
- React
- Google Cloud Run
- Google Cloud Load Balancing
- Supabase
- PostgreSQL
- CDN
- Google Cloud
Services used
- Service: Launch-day readiness · Performance and reliability
Your biggest day shouldn't be your first real load test.
- Service: SaaS development and web platforms · Product engineering
Custom web applications, APIs and integrations, built to be inherited.
- Service: Cloud, DevOps and cost · Performance and reliability
Deployments you don't dread, backups you've actually tested, and a cloud bill that makes sense.
Where this work happened
- Working with teams in India · Mumbai · Bengaluru
A senior software engineer in Mumbai for Indian startups and product teams, on the same clock as you and close enough to meet in person when a session is worth it. It is for founders with a consumer launch to scale, a media or publishing platform to keep fast, or a PHP system to modernise.
Related writing
- Article: How a voting platform held up through a 22-day campaign · 2 November 2026
The architecture behind the InfluencerX voting platform: Cloud Run behind a load balancer with health checks, layered caching and Supabase.