MegaMoves

MegaMoves is the most architecturally ambitious platform we've built. Players compete in time-boxed prediction rounds where every entry, score update and payout has to be processed in real time — and every rupee has to reconcile perfectly at the end of each round. That combination of raw speed and financial correctness, at the scale of thousands of concurrent players, shaped every decision we made from day one.

The first design question was how to keep a real-money system both fast and provably correct. We decomposed the platform into roughly eighteen Spring Boot microservices with clean bounded contexts — wallet, rounds, scoring, catalogue, users, notifications and more — so each domain could scale, deploy and be reasoned about independently. A monolith would have been faster to start but would have collapsed under the mix of write-heavy game traffic and money-movement logic that each need very different guarantees.

Round lifecycle is the heartbeat of the product: rounds open, entries lock at a cut-off, scores are computed, and winners are settled — over and over, on tight schedules. Rather than lean on brittle cron scripts, we drove this with scheduled jobs plus Netflix Conductor workflows, which give us durable, retryable and observable multi-step orchestration. If a settlement step fails midway, Conductor resumes it from the last successful point instead of leaving money in an ambiguous state.

The real-time core runs on Apache Kafka and Apache Flink. Player actions and game events stream through Kafka as an immutable log, and Flink computes live scores over tight time windows so leaderboards, standings and payouts update in near real time rather than on a delayed batch. Because everything flows through an event log, we also get a natural audit trail — every state change is replayable, which is invaluable when you have to answer 'why did this player win this amount?' months later.

For storage we chose ScyllaDB to back the low-latency, high-write game state and ledgers. Traditional relational databases struggled with the write amplification of live scoring across many rounds and players; ScyllaDB's Cassandra-compatible, wide-column model absorbed that throughput while keeping read latency low for the leaderboards players stare at. Idempotency keys and careful transaction boundaries ensure a round settles exactly once — no double payouts, no lost winners, even under retries and partial failures.

Finally, we delivered three client surfaces from a single platform: a React back-office for operators to manage rounds, catalogues and payouts; a public marketing-and-play web app; and a Flutter mobile app for players. Because the rules, scoring and money logic all live behind the same services, admin, web and native stay perfectly consistent — there's a single source of truth, not three subtly different implementations drifting apart.