Katkat
Back

Design a Fault-Tolerant Online Chess Service

OpenAISoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a stateful, fault-tolerant system where move ordering, clock synchronization, and session persistence are critical for game integrity.

Problem Statement

Design a high-availability online chess service that supports thousands of concurrent matches. Each game must maintain a strict move order, server-side clock management, and persistent game history. The system must remain resilient to individual server failures, network partitions, and client disconnects without causing race conditions or move duplication.

Functional Requirements

  • Move Validation: Every move must be validated against the current board state and player turn.
  • Clock Management: Time is managed on the server side; clients only receive updates. When a player disconnects, the clock must continue to tick.
  • Persistence: Game history must be stored as an append-only log to ensure auditability.
  • Reconnect Mechanism: Players must be able to rejoin an ongoing game seamlessly.

Non-Functional Requirements

  • Fault Tolerance: If a game server instance crashes, the game state must be recoverable within seconds.
  • Idempotency: A client retry after a network timeout should not result in the same move being applied twice.
  • Consistency: Both players must see the same move sequence, even if they experience varying network latencies.

Requirements for your Design

  1. Propose an architecture for handling real-time WebSocket connections and persistent game state.
  2. Define the schema or structure for the move log to ensure order and idempotency.
  3. Explain how the system handles failover if a dedicated 'match server' crashes.
  4. Describe how spectators can follow the game with minimal latency.

Hints

Hint 1

Consider using an actor model or a distributed lock service (like Redis or Zookeeper) to ensure only one server instance is the authoritative 'owner' of a specific game ID at any given time.

Hint 2

To achieve idempotency, include a monotonic move counter or a unique client-generated request ID for every move submitted by a player.

Hint 3

For fault tolerance, use a write-ahead log or an event-sourcing pattern where the game state can be rebuilt by replaying moves from the persistent store.

Follow-up questions

  • How would you handle a scenario where a player claims the server clock is inaccurate due to network lag?
  • How does your design change if you need to support 100,000 concurrent games versus 100 games?
  • What strategies would you implement to detect and prevent 'engine cheating' using server-side analysis during or after the match?