#18 tic tac toe game
Here’s a complete, time-boxed, 1-hour interview-ready answer for designing a Tic-Tac-Toe game system (can be extended to online multiplayer). It follows your usual system design interview structure, including functional & non-functional requirements, APIs/data model, architecture, deep dive, and trade-offs.
0 – 5 min — Problem recap, scope & assumptions
Goal: Design a Tic-Tac-Toe game system that allows two players to play a match in real-time or asynchronously. The system should handle multiple concurrent games, maintain game state, enforce game rules, and allow players to view history and statistics.
Scope for interview:
Game logic and rule enforcement.
Multiplayer support (real-time vs turn-based).
Player matchmaking and session management.
Persistence of game history and leaderboard.
Optional: scalability for large number of concurrent games.
Assumptions:
Board size: 3x3.
Two players per game.
Real-time gameplay via web or mobile client.
Target concurrent users: 10k–100k (small for scaling exercise).
Support asynchronous games where players take turns without being online simultaneously.
5 – 15 min — Functional & Non-Functional Requirements
Functional Requirements
Must
Game creation: Player can create a new game session.
Player matchmaking: Invite friend or match with random opponent.
Turn-based moves: Enforce alternating moves; prevent illegal moves.
Win/Draw detection: Check for win conditions or draw.
Game state management: Maintain current board, moves history, current turn.
Player notifications: Notify opponent when a move is made.
Game history: Persist past games and results.
Should
Allow spectators to watch games.
Support rematch requests.
Provide in-game chat or emojis.
Nice-to-have
Leaderboard and ranking based on wins/losses.
Achievements or statistics (win streaks, fastest wins).
Support multiple board sizes (NxN).
Non-Functional Requirements
Availability: System should be highly available; games shouldn’t be interrupted.
Latency: Real-time moves latency < 200ms.
Scalability: Handle thousands of concurrent games.
Durability: Game state and history must be reliably persisted.
Consistency: Enforce strong consistency for moves (no two moves on same cell).
Security: Authenticate players; prevent cheating.
Monitoring: Track active games, errors, latency.
15 – 25 min — API / Data Model
APIs
Game Management
Player Management
Data Models
Game
Player
Leaderboard
25 – 40 min — High-level architecture & data flow
Components
Client: Web or mobile interface; displays board, sends moves, receives updates.
Game Service: Core game logic, rule enforcement, winner/draw detection, turn validation.
Storage / DB: Persist game state, history, and player stats (can use SQL or NoSQL).
Notification Service: Push updates to opponent or spectator in real-time (WebSocket, Pub/Sub).
Matchmaking Service: Optional service to pair players automatically.
Data flow example
Player1 creates game → Game Service creates new Game in DB.
Player2 joins → Game status updated to ONGOING.
Player1 makes a move → validated → board updated → move stored in DB → Notification Service informs Player2.
Game continues until WIN or DRAW → status updated, stats updated.
40 – 50 min — Deep dive — consistency, real-time updates, scaling
Consistency
Use strong consistency for game state (DB transaction or in-memory lock per game).
Prevent race conditions: only current_turn player can make a move.
Real-time updates
Use WebSocket or server-sent events to push moves to opponent instantly.
For asynchronous games, store notifications and deliver when opponent comes online.
Scaling
Horizontal scaling by sharding games by game_id or player_id.
Cache active games in memory (Redis / in-memory store) for fast access.
Background workers for updating stats, leaderboard, and archiving old games.
Fault tolerance
Persist every move immediately.
On service crash, reload active games from DB.
Optional checkpointing for long-running matches.
50 – 55 min — Back-of-the-envelope calculations
Assumptions
10k concurrent games, each sending 1 move/min → ~167 moves/sec.
Each move: ~200 bytes → 33 KB/sec → ~2.85 GB/day if stored long-term.
Active games cache: ~1 KB per move x 10k games → 10 MB in memory (very small).
DB: SQL or NoSQL sufficient for this scale.
Latency
Real-time move delivery: < 200 ms achievable with WebSocket and in-memory caching.
Storage
Persist all moves in DB for history, archive old games to long-term storage if needed.
55 – 58 min — Monitoring & ops
Monitoring
Active games count.
Move processing latency.
DB errors / failed writes.
Notification failures.
Operational playbooks
Recover in-progress games after service crash.
Handle network disconnects (reconnect client & update board state).
Manage leaderboard and stats update failures.
58 – 60 min — Trade-offs, evolution & summary
Trade-offs
Real-time vs async: Real-time requires WebSockets, faster updates; async simpler but may delay moves.
In-memory vs DB-first: In-memory cache improves latency; DB persistence ensures durability.
SQL vs NoSQL: SQL easier for joins (stats, leaderboard); NoSQL simpler for sharding and high write throughput.
Evolution
MVP: simple 3x3 game, two players, real-time moves, basic stats.
Phase 2: add matchmaking, spectator mode, chat, rematch.
Phase 3: leaderboard, achievements, multi-board sizes, AI opponent.
Summary
Build a scalable, real-time Tic-Tac-Toe system:
Game Service enforces rules and stores moves.
DB persists state and stats.
Notification service updates players in real-time.
System handles thousands of concurrent games with low latency and ensures consistency and durability.
If you want, I can next produce a sequence diagram for a single Tic-Tac-Toe game flow, showing game creation → move → state update → notification.
Do you want me to create that?
Last updated