Special moves (castling, en passant) in LLD - System Design Exercise

Design: Chess Special Moves Handler

Design focuses on the logic and architecture for handling special chess moves castling and en passant within a chess game system. It excludes UI design and full chess engine implementation.

Functional Requirements

FR1: Support castling move with all rules validation (king and rook unmoved, no check on path, no pieces between)

FR2: Support en passant move with correct capture logic and timing (only immediately after opponent pawn moves two squares)

FR3: Integrate with existing chess game state and move validation system

FR4: Provide clear feedback on move legality

FR5: Allow querying current special move availability per player

Non-Functional Requirements

NFR1: Must respond to move validation requests within 50ms

NFR2: Handle up to 1000 concurrent games in memory

NFR3: Ensure correctness and consistency of game state after special moves

NFR4: Availability target 99.9% uptime for move validation service

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Game state manager

Move validator module

Special moves handler component

Event or command processor for moves

In-memory cache or database for game states

Design Patterns

State machine pattern for game state transitions

Command pattern for move execution

Observer pattern for notifying move results

Rule engine or strategy pattern for move validation

Reference Architecture

  +-------------------+       +---------------------+       +---------------------+
  |                   |       |                     |       |                     |
  |  Game State Store +<----->+  Special Moves       +<----->+  Move Validator      |
  |  (In-memory DB)   |       |  Handler Component   |       |  Module              |
  |                   |       |                     |       |                     |
  +-------------------+       +---------------------+       +---------------------+
           ^                            ^                             ^
           |                            |                             |
           |                            |                             |
           +----------------------------+-----------------------------+
                                        |
                                +----------------+
                                | Client / UI    |
                                +----------------+

Components

Game State Store

In-memory data structure or Redis

Stores current board positions, piece states, move history, and flags for special moves eligibility

Special Moves Handler Component

Custom logic module in chosen language

Encapsulates rules and validation logic for castling and en passant moves

Move Validator Module

Service or library

Validates all moves including special moves by consulting game state and special moves handler

Client / UI

Chess frontend or API consumer

Sends move requests and receives validation results

Request Flow

1. Client sends a move request to the Move Validator Module.

2. Move Validator queries Game State Store for current board and move history.

3. Move Validator calls Special Moves Handler to check if move is castling or en passant and validate rules.

4. Special Moves Handler checks conditions: for castling, verifies king and rook unmoved, path clear, no check; for en passant, verifies last move was opponent pawn two squares, target square correct.

5. Special Moves Handler returns validation result to Move Validator.

6. Move Validator returns final move legality to Client.

7. If move is valid and special, Game State Store updates board and flags accordingly.

Database Schema

Entities: - Game: id, current_turn, status - BoardState: game_id, piece_positions (map of square to piece), move_history (list of moves) - PieceState: piece_id, has_moved (boolean), position - SpecialMoveFlags: game_id, castling_rights (per player and side), en_passant_target_square, en_passant_valid_turn Relationships: - Game 1:1 BoardState - BoardState 1:N PieceState - Game 1:1 SpecialMoveFlags

Scaling Discussion

Bottlenecks

Game State Store memory usage grows with number of concurrent games

Move Validator latency increases with complex validation logic

Concurrency conflicts when multiple moves processed simultaneously for same game

Solutions

Use efficient in-memory data structures and evict finished games to reduce memory

Optimize validation logic with caching and early exits for common cases

Implement locking or transactional updates per game to avoid race conditions

Interview Tips

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

Explain how special moves have unique rules requiring dedicated logic

Describe how game state tracks piece movement and special flags

Show clear separation of concerns between validation and state management

Discuss concurrency and consistency challenges in multi-game environment

Mention latency and availability targets and how design meets them