Win condition checking in LLD - System Design Exercise

Design: Win Condition Checking System

Design focuses on the logic and architecture for checking win conditions in turn-based games. UI, networking, and player matchmaking are out of scope.

Functional Requirements

FR1: Support multiple game types (e.g., Tic-Tac-Toe, Connect Four, Chess) with different win conditions

FR2: Check if a player has won after each move

FR3: Provide real-time feedback on game status (win, draw, ongoing)

FR4: Allow easy addition of new game types and win conditions

FR5: Ensure correctness and efficiency in win condition evaluation

Non-Functional Requirements

NFR1: Must handle up to 1000 concurrent games

NFR2: Win check latency should be under 50ms per move

NFR3: System availability should be 99.9%

NFR4: Memory usage should be optimized for embedded or low-resource environments

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Game state manager to hold current board or game data

Win condition evaluator module with pluggable rules

Move processor to update state and trigger checks

Result notifier to inform about game status

Configuration loader for different game rules

Design Patterns

Strategy pattern for different win condition algorithms

Observer pattern for notifying game status changes

State pattern for managing game phases

Command pattern for moves and undo functionality

Reference Architecture

  +---------------------+
  |   Move Processor    |
  +----------+----------+
             |
             v
  +----------+----------+       +---------------------+
  |  Game State Manager  |<---->|  Configuration Loader |
  +----------+----------+       +---------------------+
             |
             v
  +----------+----------+
  | Win Condition Evaluator |
  +----------+----------+
             |
             v
  +----------+----------+
  |   Result Notifier    |
  +---------------------+

Components

Move Processor

Custom logic module

Receives player moves, validates them, and updates the game state

Game State Manager

In-memory data structures

Maintains current state of the game board or pieces

Configuration Loader

JSON/YAML config files

Loads rules and win condition definitions for different games

Win Condition Evaluator

Strategy pattern implementations

Checks if the current game state meets any win or draw conditions

Result Notifier

Event emitter or callback system

Notifies the system or players about game results or ongoing status

Request Flow

1. Player submits a move to Move Processor

2. Move Processor validates and updates Game State Manager

3. Game State Manager provides updated state to Win Condition Evaluator

4. Win Condition Evaluator applies game-specific rules to check for win/draw

5. Result Notifier sends status update (win/draw/ongoing) to the game controller or UI

Database Schema

Not applicable as system is designed for in-memory low-latency checking; persistent storage is out of scope.

Scaling Discussion

Bottlenecks

High concurrency causing contention on shared game state

Complex win condition logic increasing latency

Memory usage growing with many concurrent games

Solutions

Partition games across multiple instances or threads to reduce contention

Optimize win condition algorithms with early exits and caching

Use lightweight data structures and clean up finished games promptly

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and optimizations, 5 minutes summarizing.

Emphasize modular design for supporting multiple games

Explain choice of design patterns for flexibility and maintainability

Discuss trade-offs between latency and complexity

Highlight how to handle concurrency and resource constraints

Show awareness of real-time feedback importance