Ballpe — Live Cricket.
Real-Time Quiz. Real Money.
A real-time quiz contest platform built on live cricket — pool contests, MCQ battles, head-to-head matchups, and event-triggered live questions firing on every wicket, boundary, and over. 6,00,000 downloads. 4,00,000 concurrent users. ₹2Cr+ in revenue.
What is Ballpe?
Ballpe is a real-time cricket quiz contest platform — a category that didn't exist at this level of execution before we built it. Users join pool contests, head-to-head matchups, or MCQ battles tied to live cricket matches. As the match unfolds, pre-written questions fire automatically on match events — a wicket falls, a question appears. A six is hit, another fires. Every answer is timed. Every rupee is real.
The platform sits at the intersection of live sports data, real-time question delivery, and real money contest infrastructure — three hard problems that each have their own failure modes. We built the entire system end-to-end: score ingestion, event-to-question mapping engine, four contest formats, 4,00,000 concurrent user broadcast layer, and prize settlement.
Live cricket + real money + quiz = three failure surfaces at once.
Most quiz apps are turn-based and asynchronous. Most fantasy apps are pre-match. Ballpe is neither — it's a real-time, event-driven, real money product where questions must fire within seconds of a match event, 4,00,000 users must receive them simultaneously, and every answer window is counted in seconds. One failure layer takes the whole product down.
- No existing platform delivered event-triggered quiz questions tied to live match moments — the category had to be built from scratch
- Question delivery to 4,00,000 concurrent users had to be near-instantaneous — a 10-second delay after a wicket made the question feel disconnected from the match
- Four contest formats (Pool, MCQ, Head-to-Head, Live) required four separate matching, scoring, and settlement engines — not variations of one
- Answer window enforcement at scale — closing a 15-second answer window simultaneously for 4,00,000 users with no race conditions on late submissions
- Score API latency meant match events reached the platform with variable delay — question firing couldn't be naively tied to API polling intervals
- Custom event-to-question mapping engine — pre-written questions tagged to match event types, fired automatically when corresponding event received from score API
- WebSocket broadcast layer stress-tested to 4,00,000 concurrent connections with sub-3-second question delivery from event trigger to user screen
- Four independently architected contest engines sharing a common wallet and settlement layer — each format has its own matching, scoring, and payout logic
- Server-side answer window enforced via Redis TTL — submissions after window expiry rejected at API level, not client level
- Event deduplication layer on score ingestion — duplicate or out-of-order API events filtered before question trigger, preventing double-fires on the same match moment
Built to feel premium at every screen.
Every screen was designed with the end-user in mind — someone on the move, often distracted, who needs information fast and decisions to be obvious.
Four contest formats. One live match. Zero tolerance for lag.
Each contest format is an independent product in complexity. Together they make Ballpe the most feature-complete live cricket quiz platform in the Indian market.
Pre-written questions tagged to match event types — wicket, six, four, maiden over, century. When the event fires from the score API, the mapped question is broadcast to all active contest participants within 3 seconds.
Large entry pools where all participants answer the same question set. Points accumulate across the match. Prize pool distributed to top-ranked players at match end based on total correct answers and speed.
Multiple choice question format with speed scoring — faster correct answers earn more points. Separate contest lobby, separate leaderboard, same live question feed. Designed for casual players who want lower stakes.
1v1 contest format — two players matched against each other on the same live question feed. First to accumulate more correct answers across the match wins the pot. Instant prize credit on match completion.
In-app wallet with UPI and card deposits. Contest entry fees held in escrow. Prize distribution within 10 minutes of match end across all active contest formats simultaneously. TDS compliance built in.
Match scheduling, question bank management, event-to-question mapping configuration, live match monitoring, contest health dashboard, and prize settlement oversight — all from one panel.
The numbers.
All real.
Stack chosen for event-driven real-time scale.
React Native CLI for raw animation performance on timed question UI. Everything backend chosen around one constraint: a match event must reach 4,00,000 screens in under 3 seconds.
Architecture built around the match event pipeline.
Everything in Ballpe flows from a single trigger — a match event received from the score API. The architecture was designed so that pipeline is fast, deduplicated, and fault-tolerant. Everything downstream — question delivery, answer windows, scoring, settlement — depends on it.
- Score events received from SportRadar webhook, validated and written to BullMQ event queue — processing decoupled from ingestion, no blocking on high-frequency ball events
- Event processor checks event type against question mapping table — each event type (WICKET, SIX, FOUR, MAIDEN, CENTURY) has N pre-written questions in rotation
- Question selected via round-robin from mapped pool — same event type never fires the same question twice in consecutive matches
- Deduplication layer checks event ID against Redis set with 60-second TTL — duplicate webhook deliveries and out-of-order events silently dropped before trigger
- Question broadcast via Redis pub/sub fan-out to all Socket.IO nodes — single publish reaches all 4,00,000 connected clients regardless of which node they're on
- Answer window opened server-side via Redis key with TTL equal to contest's configured window (10–30 seconds) — key expiry is the authoritative window close
- Late answer submissions checked against Redis key existence — if key expired, submission rejected with 410 Gone response, no client-side trust
- AWS Auto Scaling pre-warmed 30 minutes before scheduled match start — same pattern as My11Cricket, instances ready before spike not after
- Pool, MCQ, Head-to-Head, and Live contests run as independent state machines — each has its own scoring rules, leaderboard, and settlement logic sharing only the wallet layer
- Head-to-Head matching via Redis queue — players enqueued on contest join, dequeued in pairs, room created atomically to prevent three-player rooms
- Post-match settlement job triggered by MATCH_COMPLETED event — all four contest engines settle in parallel via separate BullMQ queues, prizes credited within 10 minutes
- TDS deduction computed per winner per contest at settlement — compliance ledger written before wallet credit, never after
Four failure modes we solved before launch.
Event-driven real money gaming at 4,00,000 concurrent users has failure modes that don't appear in any other product category. These four were the critical ones.
- 01Duplicate event firing — score API delivered the same match event twice under load, causing the same question to appear twice in rapid succession and confusing users
- 02Answer window race condition — users submitting answers in the final 100ms of a window had submissions accepted by one server node and rejected by another depending on clock drift
- 03Head-to-head room imbalance — three players joining simultaneously could result in one player matched twice or one player left unmatched with no contest to join
- 04Simultaneous settlement of four contest formats after match end caused wallet credit contention — parallel updates to the same user's wallet from multiple contest payouts created race conditions
- Event deduplication via Redis SET with NX flag — first processor to claim an event ID owns it, all subsequent processors skip it. Duplicate fires structurally impossible
- Answer window authoritative source is Redis key TTL, not server clock — all nodes check the same Redis key, clock drift irrelevant. Window close is atomic across the entire cluster
- Head-to-head room creation via Redis MULTI/EXEC atomic transaction — exactly two players dequeued per room creation, odd-player-out re-queued automatically for next match cycle
- Wallet credits serialized via per-user Redis lock during settlement — each user's payouts from all four contest formats processed sequentially, never concurrently
“Ballpe is the hardest product in this portfolio to build correctly — not because any single system is complex, but because four complex systems have to work in perfect sequence, in real time, with real money on the line, while 4,00,000 people watch the same cricket match. Getting that right required solving problems most teams don't even know exist until their first live match.”
Event-driven question delivery, real-time contest mechanics, and real money settlement at scale — this is a category where the engineering complexity is the product. Let's talk.