Scaling from 300 to 20 lakh users isn't about adding more servers. It requires a fundamental rethink of architecture, database design and real-time processing.
The concurrency problem
Most apps have traffic spread across the day. A fitness platform like HABUILD is different: everyone logs in at exactly 6:00 AM.
Peak load looked like this:
- Morning login spikes: 80,000+ hits/minute
- Database writes (attendance): 5,000+ ops/second
Our solution architecture
- Microservices strategy — we decoupled the notification engine from core session verification, so one could never bottleneck the other.
- Smart caching & shortlinks — a custom short-link system handling 60–80k hits/day at sub-millisecond latency, backed by Redis.
- CI/CD & auto-scaling — AWS auto-scaling groups that spin up instances 15 minutes before scheduled sessions, ahead of the surge instead of in reaction to it.
Engineering the "perfect" session
How do you track attendance for 10,000 people on Zoom and YouTube simultaneously?
- Cross-platform tracking — whether a user joins via the Zoom app, a browser, or YouTube Live, a custom wrapper captures session start and end events.
- Real-time analytics — attendance streams into a live dashboard, giving trainers instant feedback on participation and drop-off.
- Data integrity — automated reconciliation ensures a network blip never costs a loyal member their attendance streak.
The numbers that matter
- 20 lakh members supported
- 99.99% platform uptime
- 0.2s API latency
- Terabytes of data processed
Architecture like this is invisible when it works — members just see a class that starts on time, every time. If your platform needs to survive its own 6 AM moment, talk to our engineers.