Player turn management in LLD - System Design Exercise

Design: Player Turn Management System

Design focuses on managing player turns within game sessions. Does not cover game logic, player authentication, or UI design.

Functional Requirements

FR1: Manage turns for multiple players in a game session

FR2: Support adding and removing players dynamically

FR3: Ensure turn order is maintained correctly

FR4: Allow skipping or reversing turn order

FR5: Notify players when it is their turn

FR6: Handle concurrent actions gracefully

FR7: Support multiple game sessions independently

Non-Functional Requirements

NFR1: Support up to 10 players per game session

NFR2: Turn notification latency under 100ms

NFR3: System availability 99.9%

NFR4: Handle up to 1000 concurrent game sessions

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Turn manager service

Player session manager

Notification system

Data store for game sessions and player states

Concurrency control mechanism

Design Patterns

State machine for turn states

Observer pattern for notifications

Queue or circular linked list for turn order

Event-driven architecture for turn changes

Reference Architecture

                    +---------------------+
                    |  Client (Player UI)  |
                    +----------+----------+
                               |
                               | WebSocket / REST API
                               |
                    +----------v----------+
                    |   Turn Manager      |
                    |  (State Machine)    |
                    +----------+----------+
                               |
          +--------------------+--------------------+
          |                                         |
+---------v---------+                     +---------v---------+
| Player Session DB  |                     | Notification Svc  |
| (Game & Player    |                     | (Push messages)   |
|  states storage)  |                     +-------------------+
+-------------------+

Components

Turn Manager

In-memory state machine or service

Controls turn order, manages turn transitions, supports skip/reverse

Player Session DB

Relational or NoSQL database

Stores game sessions, player lists, and current turn state

Notification Service

WebSocket server or push notification system

Sends real-time turn notifications to players

Client (Player UI)

Web or mobile app

Displays turn status and receives notifications

Request Flow

1. 1. Player connects to the game session via client UI.

2. 2. Turn Manager loads current game session and player list from Player Session DB.

3. 3. Turn Manager determines whose turn it is based on stored order.

4. 4. Notification Service sends a message to the current player that it is their turn.

5. 5. Player performs action and signals turn completion to Turn Manager.

6. 6. Turn Manager updates turn order (advances, skips, or reverses as needed) and updates Player Session DB.

7. 7. Turn Manager notifies the next player via Notification Service.

8. 8. Repeat steps 4-7 until game session ends or players leave.

Database Schema

Entities: - GameSession: id (PK), status, created_at - Player: id (PK), name, connected_status - GamePlayer: id (PK), game_session_id (FK), player_id (FK), turn_order_index - TurnState: game_session_id (PK, FK), current_turn_index, direction (normal/reverse), last_updated Relationships: - GameSession has many GamePlayers - GamePlayer links Player to GameSession with turn order - TurnState tracks current turn position and direction per GameSession

Scaling Discussion

Bottlenecks

Turn Manager becomes a single point of failure under high concurrent sessions

Notification Service may overload with many simultaneous messages

Database contention when many sessions update turn state concurrently

Solutions

Partition Turn Manager by game session (sharding) to distribute load

Use scalable pub/sub or message queue systems for notifications

Implement optimistic concurrency control or use lightweight transactions for turn state updates

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Clarify turn order rules and player dynamics

Explain choice of state machine for turn management

Discuss real-time notifications and latency considerations

Highlight data consistency and concurrency handling

Address scaling strategies and fault tolerance