LuckyColor — Predict. Win.
30,000 Players. One Minute.
A real-time P2P color prediction game where 30,000+ players simultaneously pick a number or color, wait 60 seconds, and the winner walks away with 180% of their stake — built on a custom pool-matching engine designed for fairness, speed, and operator margin.
What is LuckyColor?
LuckyColor is a real-time P2P color prediction game for the Indian real money gaming market. Every 60 seconds, a new round opens. Players pick a color or number — Red, Green, or Violet — place their stake, and wait for the result. Winners receive 180% of their stake. The round closes, the pool settles, and the next one begins.
The deceptively simple mechanic sits on top of a complex P2P pool-matching engine — one that has to balance player pools, compute outcomes fairly, process payouts instantly, and hold under 30,000 simultaneous players without a single round desync. We built every layer of it.
Simple game. Brutal engineering problem.
Color prediction games are the most played category in Indian real money gaming — and the most poorly built. Every existing product was either a clone with a broken payout model, or a house-vs-player setup disguised as P2P. Neither builds long-term trust.
- Existing color prediction apps ran house-vs-player models dressed up as P2P — players eventually noticed and churned
- No platform had a true pool-matching engine that balanced Red/Green/Violet pools in real time before round close
- Payout at 180% with a platform cut required precise pool math — most implementations leaked margin or underpaid winners
- 30,000 simultaneous players in a 60-second round window created extreme write contention on bet and settlement tables
- APK distribution (outside Play Store) meant no update enforcement — stale clients caused round state mismatches
- True P2P pool model — player stakes fund winner payouts directly, platform takes a transparent cut from the pool
- Real-time pool balancing engine that tracks Red/Green/Violet distribution and closes betting when pools are settleable
- 180% payout formula engineered with platform margin baked into pool sizing rules, not outcome manipulation
- Redis-backed atomic bet writes with round-scoped locks — 30,000 concurrent bets processed without contention or double-booking
- Forced version-check on app open with APK update flow — stale clients cannot enter a round
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.
Six systems powering every 60-second round.
Each round is a mini financial transaction at scale. Every system below had to be real-time, atomic, and bulletproof.
Players select Red, Green, or Violet (and an optional number) before round close. Result is determined from the settled pool — winners receive exactly 180% of their stake, instantly.
Custom-built pool engine that aggregates all player stakes by color in real time, computes the settleable outcome, deducts platform margin, and distributes payouts — no house bank required.
Synchronized round clock broadcast to all 30,000+ connected clients simultaneously. Betting locks at T-5 seconds. Result computed and pushed within 500ms of round close.
Winner wallets credited within 1 second of result announcement. Atomic ledger updates — no partial settlements, no delayed credits, no reconciliation backlog.
In-app wallet with UPI and card deposit support. Withdrawal requests processed with velocity checks and fraud scoring. Full transaction history with round-level audit trail.
Live round monitoring, pool distribution visibility, payout logs, player activity dashboard, and margin reporting per round — built for operators who need full financial control.
The numbers.
Real where confirmed, estimated where noted.
Stack chosen for 60-second settlement at scale.
Every choice was pressure-tested against one scenario: 30,000 players submitting bets in the same 55-second window, with results due in under a second.
Architecture built around the 60-second window.
P2P pool settlement sounds simple. In practice it's a distributed transaction problem — you're aggregating thousands of writes, computing a shared outcome, and crediting winners, all within a single minute, with no room for partial state.
- Each round opens a scoped pool in Redis — all bets written as atomic increments to color-keyed counters (RED_POOL, GREEN_POOL, VIOLET_POOL)
- Pool balancing logic monitors distribution in real time — admin can configure minimum pool thresholds before a round is settleable
- Platform margin deducted from gross pool before winner distribution — margin rate is configurable per deployment, transparent to players
- Winner payout computed as: (player_stake / winning_color_pool) × (gross_pool × (1 - platform_margin)) — no rounding errors, no leakage
- Socket.IO cluster with Redis adapter — round clock, pool size updates, and result broadcast pushed to all clients from single authoritative server loop
- Bet submission locked at T-5 seconds via server-side round state machine — late bets rejected at API level, not just UI level
- Round lifecycle: OPEN → BETTING → LOCKED → RESULT → SETTLED — each transition is atomic and logged, no intermediate states possible
- Result pushed to all 30,000+ clients within 500ms of settlement — tested under full load with <120ms p99 broadcast latency
- Wallet ledger implemented as append-only event log — every debit and credit is immutable, auditable to the round level
- Atomic payout using Redis Lua scripts — winner credits execute in a single transaction, impossible to double-credit on retry
- Withdrawal fraud scoring on velocity (requests/hour), amount deviation, and account age — high-risk withdrawals routed to manual queue
- APK version enforcement on every socket connection — outdated clients receive forced update prompt and cannot submit bets
What we solved that most teams don't anticipate.
P2P pool games at scale have failure modes that only appear under real load. These four nearly broke the product — and how we fixed each one.
- 01Write contention on bet tables — 30,000 players submitting bets in a 55-second window created severe database lock contention in early testing
- 02Pool imbalance edge cases — rounds where 90%+ of players picked the same color, making 180% payout mathematically unsustainable from the pool alone
- 03APK-distributed app with no forced update mechanism — stale clients on older round logic caused bet submission failures and player complaints
- 04Payout disputes — players claiming they didn't receive winnings when network drops caused the credit confirmation to not reach the client
- Moved all bet writes to Redis atomic counters — database only written at round settlement, reducing write ops by ~98% during active betting
- Minimum pool threshold system — if any color pool is below viable payout level at T-10s, round auto-extends by 30 seconds and notifies players
- Version handshake on socket connect — server rejects connections from outdated APK versions and serves a deep-link to the latest APK download
- Wallet state pushed via WebSocket post-settlement regardless of payout API response — client always receives updated balance from server, not from API confirmation
“Color prediction is the most competitive, most copied category in Indian real money gaming. Everyone has the same UI. The operators who survive are the ones whose pool math doesn't leak and whose infrastructure doesn't fall over on a big round. That's what we built.”
Pool mechanics, real-time settlement, fraud prevention — this is a space where generic agencies get you burned. Let's talk.