Shared state
Nine players, nine devices, one hand in progress. Each client has to see the same pot, the same action and the same clock, and the server has to remain the only authority on all three.
Real-Time Multiplayer, Where Every Millisecond Is a Fairness Question
PokerBaazi is one of India's largest homegrown poker platforms, built by Baazi Games. Thousands of simultaneous tables, synchronised turn by turn across mobile networks, on infrastructure where a dropped connection has to be handled as a rules question rather than a refresh.
Build Your Real-Time PlatformAbout the Project
PokerBaazi is the poker vertical of Baazi Games, an Indian skill-gaming company founded in 2014 that also operates BalleBaazi for fantasy sports and RummyBaazi for rummy. The platform runs Texas Hold'em and Pot Limit Omaha cash games and tournaments, and states a registered base of more than six million players. Following India's 2025 online gaming legislation, PokerBaazi moved to a mobile-first, subscription-based free-play model in which players earn redeemable reward points — a change in commercial model that leaves the underlying real-time engineering problem unchanged.
Industry
Online Skill Gaming and Real-Money Entertainment
A category where the software is the game: correctness, fairness and latency are the product, and a defect is visible to every player at the table at once.
The Platform
Texas Hold'em and Pot Limit Omaha, cash tables and tournaments
Baazi Games states PokerBaazi is home to more than six million players, running scheduled tournaments alongside continuous cash games.
Real-Time Core
WebSocket game state, Redis in memory, Node services on AWS
The stack recorded for this project: persistent socket connections carrying table state, Redis holding the state that cannot wait on a database, MongoDB for durable records and AWS underneath.
Players
Recreational players and serious grinders on the same tables
One audience plays a few hands on a commute, the other plays several tables at once for hours. The same client has to serve both without favouring either.
Operating Context
Indian mobile networks, Indian regulatory change
A platform in this category has to hold a synchronous game together over inconsistent mobile connectivity, and absorb regulatory shifts that change the commercial model without rewriting the game engine.
Build your idea
Talk to our experts
Scope a real-time multiplayer, live-event or high-concurrency consumer platform.
A Poker Table Is a Distributed System That Cannot Disagree With Itself
Every player holds a view of the same hand, and any divergence between those views is not a bug report — it is a dispute about money.
Turn clocks
A turn timer is part of the rules. That makes network delay a fairness problem: a player whose connection lags must not lose a hand to latency, and a player who exploits the timer must not gain from it.
Peak nights
Traffic in this category is spiky by design. Scheduled tournaments start at an announced time, which means the platform meets its highest concurrency at a moment everyone already knows about.
Thousands of tables,
one authoritative state,
held together over mobile networks
Build Your Real-Time Product
How a Platform Like This Is Built
-
Authoritative Game Server
Authoritative Game Server
- The server owns the hand: deal, action order, pot and showdown are decided server-side and broadcast, never computed on a client
- Clients render state and send intent, which is what keeps a modified or stale client from affecting the outcome of a table
- Node services carry the game loop, chosen for connection concurrency rather than raw computation
-
WebSocket State Synchronisation
WebSocket State Synchronisation
- Persistent socket connections push table state to every seat, so action, timer and pot move together across devices
- Reconnection is a first-class path: a player who drops mid-hand rejoins the hand as it stands rather than restarting a session
- Message volume is shaped per table, because a broadcast per keystroke across thousands of tables is its own outage
-
In-Memory State With Durable Records
In-Memory State With Durable Records
- Redis holds live table state, where a database round trip per action would show up directly as lag at the table
- MongoDB carries the durable side — accounts, hand history, results — that has to survive a process restart
- The split matters most on recovery: live state can be rebuilt, but a settled hand has to be reconstructable exactly
-
Scaling for Scheduled Peaks
Scaling for Scheduled Peaks
- Tournament start times concentrate load, so capacity is planned against known peaks rather than an average
- AWS infrastructure carries the elasticity, with table distribution designed so one busy shard does not stall unrelated games
- Degradation has to be partial by design: a problem on one table cannot become a platform-wide incident
What This Build Demonstrates
Engineering for consumer scale where correctness is non-negotiable.
Real-Time Systems at Consumer Scale
Persistent connections, server-authoritative state and in-memory game data are a different discipline from request-response product work, and the constraints show up in every architectural choice.
Built for Indian Mobile Conditions
Variable connectivity is the design baseline. Reconnection, state recovery and message efficiency matter more here than they would for a product used on office broadband.
Redis and WebSocket Where They Earn Their Place
In-memory state and socket transport are chosen because a database round trip per player action would be visible at the table — not as defaults, but as answers to a specific latency budget.
A Category That Changes Around the Product
Skill gaming in India has seen its commercial model redefined by legislation. Platforms in this space need a game engine that survives a change in how play is monetised.
Global presence
