# InfluencerX > A voting platform that stayed fast for all 22 days of a campaign. - Page: https://deependra.in/work/influencerx-voting-platform - Type: Case study 01 of 6 - Last updated: 2026-11-02 - Author: [Deependra Vishwakarma](https://deependra.in/about), senior software engineer in Mumbai ## Key facts - Project: InfluencerX - Client: Exhibit Magazine India Pvt. Ltd. - What: Real-time voting platform - Role: Architect and lead engineer - Year: 2025 - Live: https://www.exhibit.tech ## 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. ## Pictures - The exhibit.tech home page on desktop: the Exhibit header, its section navigation, a featured gadget review and the People's Favorite column. ## 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 - **1.6M+**: users over the campaign. Definition: Total users of the voting platform over the campaign, not concurrent sessions. - **2,000+**: concurrent users at peak. Definition: Users on the platform at the same moment, at the busiest point of the campaign. - **99.99%**: availability over the campaign. Definition: Availability over the campaign, from the Google Cloud load balancer's health checks: no failed check and no outage was seen during the campaign. 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 - [Launch-day readiness](https://deependra.in/services/scale/launch-readiness) (Performance and reliability): Your biggest day shouldn't be your first real load test. - [SaaS development and web platforms](https://deependra.in/services/build/web-platforms) (Product engineering): Custom web applications, APIs and integrations, built to be inherited. - [Cloud, DevOps and cost](https://deependra.in/services/scale/cloud-devops) (Performance and reliability): Deployments you don't dread, backups you've actually tested, and a cloud bill that makes sense. ## Where this work happened - [India](https://deependra.in/markets/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 - [How a voting platform held up through a 22-day campaign](https://deependra.in/writing/voting-platform-22-day-campaign-architecture) (2 November 2026): The architecture behind the InfluencerX voting platform: Cloud Run behind a load balancer with health checks, layered caching and Supabase. --- Cite as: Deependra Vishwakarma, "InfluencerX", https://deependra.in/work/influencerx-voting-platform (last updated 2026-11-02). This is the Markdown version of https://deependra.in/work/influencerx-voting-platform; the page is the canonical source. Start a project: https://deependra.in/contact