Problem framing
Design an online chess game for two players: standard 8×8 board, legal move validation, turn alternation, and game-over detection (checkmate, stalemate, resignation). Tests Composite (board of pieces), polymorphism (piece-specific movement), and separating rules from UI — common at Amazon, Microsoft, and gaming-adjacent backend loops.
| Entity | Responsibility |
|---|---|
ChessGame | Facade: makeMove(move), resign(player), getStatus() |
Board | 8×8 grid; place/remove pieces; no rule logic |
Piece (abstract) | canMove(board, from, to), getColor() |
King, Queen, Rook, … | Concrete movement rules |
Move | from, to, optional promotion piece |
Player | id, color (WHITE/BLACK) |
GameState | ACTIVE, CHECK, CHECKMATE, STALEMATE, DRAW |
MoveValidator | Orchestrates legality: piece rules + path clear + king safety |
Why not one giant Board class
Piece movement differs radically (rook straight lines vs knight L-jump). Template method or polymorphic Piece.canMove() keeps Board dumb storage. MoveValidator composes: (1) piece allows path, (2) path not blocked, (3) move doesn't leave own king in check.
Turn lifecycle
makeMove(move):
assert active player owns piece at move.from
assert MoveValidator.isLegal(move)
apply move on board (capture if needed)
if opponent king in checkmate → CHECKMATE
else if stalemate → STALEMATE
else if check → CHECK
else ACTIVE
switch turnCastling, en passant, promotion — list as extensions; implement only if interviewer asks. Promotion: Move carries promotionPiece defaulting to Queen.
Check / checkmate detection
After hypothetical move, scan opponent king attacks — brute force over opponent pieces calling canMove toward king square is acceptable in LLD (O(64×pieces)). Production engines use bitboards; don't go there unless asked.
Stalemate — king not in check but no legal moves. Draw — defer threefold repetition / 50-move rule unless specified.
Online multiplayer (awareness)
LLD focuses on game engine in memory. For "online" scope, mention separately: GameSession id, WebSocket push of moves, server authoritative validation (client moves are proposals), clock per player (ChessClock strategy). Hello Interview's system-design breakdown covers session scale; this subtopic owns class-level rules.
Senior-level signal
Board deep copy vs immutable snapshots for undo — Strategy: command history with MoveCommand objects. Discuss extensibility: Chess960 or BugHouse as new RuleSet interface without rewriting Piece hierarchy. Defer AI opponent.
Where this goes next
Rate Limiter (infrastructure topic) bridges into backend components — algorithms and thread-safety at API boundaries, the other half of senior backend LLD loops.
Further Reading
Practice Tasks (Optional)
Design or implement locally in any language — no autograding. Focus on class structure, extensibility, and being able to explain trade-offs out loud.
- Design move validation API45m
Classes: ChessGame, Board, Player, Move, Piece hierarchy (King, Queen, …), MoveValidator. API: makeMove(from, to), getStatus(). Walk through: white moves e2-e4, black attempts illegal king move into check. Note how you'd extend for castling without rewriting Board.