Cash Rummy: one authoritative table for 5,000+ players.
Production, previous startup
A card table looks simple until thousands of them run at once. Every player at a table has to see the same state within milliseconds. That state has to survive dropped connections, and no client can be allowed to change it.
- Unity and React Native clients
- Socket.io nodes, server owns the state
- Redis: shared table state
Constraints
- Turn-based play with strict timers, on unreliable mobile networks.
- Two client codebases, Unity and React Native, speaking one protocol.
- Public tables and private lobbies with invite codes.
- A small team, so operating the system had to stay simple.
Key engineering decisions
| Decision | Alternative | Why | Trade-off accepted |
|---|---|---|---|
| The server owns game state. Clients send intents, and the server validates and broadcasts the result | Client-side or peer-to-peer state | Fairness, cheat resistance, one source of truth | More server work and more round-trips |
| Table state and pub/sub in Redis, shared across nodes | In-memory state on each node | Scale out horizontally. A node can restart without losing a table | Redis becomes a critical dependency that needs close monitoring |
| Turn timers run on the server | Timers on the client | A client can't stall the game or fake a timeout | Timers have to recover when a node fails over |
| Reconnect from a state snapshot and resume | Treat a disconnect as a forfeit | Mobile connections drop often, and players should keep their place | A grace window adds complexity |
| Private lobbies with their own lifecycle | Public matchmaking only | Friends want to play together | Idle rooms need cleaning up |
Failures the system handles
- A player disconnects mid-turn.
- Client events arrive twice or out of order. Handled with idempotency (a repeated event has no extra effect) and sequence numbers.
- A node crashes while a table is active.
- Redis latency spikes.
- Private rooms are abandoned.
Results
5,000+ concurrent players at peak, in production. [Measured figures to add: p95 event latency, nodes at peak, uptime over the period]
What we'd do differently
[One or two lessons from the engineers]
Since then
We've continued developing the platform as a portfolio rebuild covering private-lobby seating, bot turns and multi-table play. That rebuild is an active engineering project, not the production system described above.
How this applies to you
If your rooms, documents, auctions or live sessions desync when you add servers, or reconnects lose progress, we've already solved that problem in production.
All code is private. We offer code walkthroughs under mutual NDA.