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

Practice

1. What is the main purpose of player turn management in a game?

easy

A. To display game graphics

B. To store player scores permanently

C. To generate random player names

D. To control the order in which players take their turns

Solution

1. Step 1: Understand the role of turn management

   Player turn management is about deciding who plays next in a game.

2. Step 2: Identify the correct purpose

   Controlling the order of play ensures fairness and structure in the game.

3. Final Answer:

   To control the order in which players take their turns -> Option D

4. Quick Check:

   Turn order = Control player turns [OK]

Hint: Turn management controls who plays next [OK]

Common Mistakes:

• Confusing turn management with score keeping
• Thinking it manages graphics or UI
• Assuming it generates player data

2. Which of the following code snippets correctly updates the current player index to the next player in a circular list of 4 players?

easy

A. current_index = (current_index + 1) % 4

B. current_index = current_index + 1

C. current_index = current_index - 1 % 4

D. current_index = current_index * 4

Solution

1. Step 1: Understand circular indexing

   To cycle through players, we add 1 and wrap around using modulo.

2. Step 2: Check each option

   current_index = (current_index + 1) % 4 correctly uses modulo to wrap index from 3 back to 0.

3. Final Answer:

   current_index = (current_index + 1) % 4 -> Option A

4. Quick Check:

   Modulo ensures circular turn cycling [OK]

Hint: Use modulo (%) to cycle player index [OK]

Common Mistakes:

• Forgetting modulo causes index overflow
• Using subtraction incorrectly
• Multiplying index instead of incrementing

3. Given the code below, what will be the value of current_player after 5 turns?

players = ['Alice', 'Bob', 'Charlie']
current_index = 0
for _ in range(5):
    current_index = (current_index + 1) % len(players)
current_player = players[current_index]

medium

A. Charlie

B. Alice

C. Bob

D. IndexError

Solution

1. Step 1: Calculate index after each turn

   Starting at 0, increment 5 times with modulo 3: Turns: 1->1, 2->2, 3->0, 4->1, 5->2

2. Step 2: Determine player at final index

   Index 2 corresponds to 'Charlie'. But since loop increments before assignment, after 5 turns current_index is 2.

3. Final Answer:

   Charlie -> Option A

4. Quick Check:

   5 turns cycle index to 2 = Charlie [OK]

Hint: Count modulo steps to find final player [OK]

Common Mistakes:

• Off-by-one error in counting turns
• Confusing index with player name
• Assuming index resets incorrectly

4. Identify the bug in the following player turn management code snippet:

players = ['Anna', 'Ben', 'Cara']
current_index = 0
while True:
    print(players[current_index])
    current_index += 1

medium

A. Players list is empty

B. The loop never ends

C. current_index will go out of range causing an error

D. Print statement is incorrect

Solution

1. Step 1: Analyze index increment without wrap

   current_index increases endlessly without modulo, so it will exceed list length.

2. Step 2: Identify resulting error

   Accessing players[current_index] beyond list size causes IndexError.

3. Final Answer:

   current_index will go out of range causing an error -> Option C

4. Quick Check:

   Missing modulo causes index error [OK]

Hint: Always wrap index with modulo to avoid errors [OK]

Common Mistakes:

• Ignoring infinite loop problem
• Assuming list is empty
• Thinking print causes error

5. You are designing a turn management system for a game with dynamic players joining and leaving. Which approach best ensures correct turn order without skipping or repeating players?

hard

A. Use a fixed-size array and modulo arithmetic on a static player count

B. Maintain a linked list of active players and move to next node each turn

C. Randomly select a player each turn without tracking order

D. Reset the current player index to zero after every turn

Solution

1. Step 1: Consider dynamic player changes

   Players can join or leave anytime, so fixed arrays won't adapt well.

2. Step 2: Evaluate linked list suitability

   A linked list allows easy insertion/removal and moving to next player without skipping.

3. Step 3: Reject other options

   Random selection breaks order; resetting index causes repeated turns; fixed array fails dynamic updates.

4. Final Answer:

   Maintain a linked list of active players and move to next node each turn -> Option B

5. Quick Check:

   Linked list handles dynamic players best [OK]

Hint: Use linked list for dynamic player turn order [OK]

Common Mistakes:

• Using fixed arrays for dynamic players
• Randomizing turns breaks fairness
• Resetting index causes repeated turns