What happens when you make a move in lichess.org?

Lichess’s move-handling architecture prompts debate over why the server, rather than the client, generates legal moves and tracks timing, with many arguing this centralization improves consistency, avoids client bugs, and enables fair lag compensation—especially for low-powered devices and fast time controls like bullet. Commenters contrast this relatively simple, mostly monolithic Scala-based stack with microservice-heavy approaches at companies like Netflix and chess.com, arguing that lichess achieves impressive scale, cost-efficiency, and reliability (despite rare outages) through careful use of Redis pub/sub, WebSockets, and server-side validation. There is also recurring criticism of chess.com’s timing and UX quality, used as a foil to highlight how small architectural choices materially affect online play fairness and experience.

Server-side move generation & historical bugs

  • Several comments discuss why the server, not the client, generates legal moves: consistency across variants, avoiding subtle client bugs, and lowering the burden for third-party clients and low-powered devices.
  • A past Lichess bug allowed an illegal castling move with a rook between king and rook; only 7 games were affected. A linked fix shows the original code incorrectly allowed intervening same-colored kings/rooks on the king’s path.

Messaging, reliability & architecture

  • Some readers wanted more detail on handling message loss with Redis pub/sub’s at-most-once delivery. Others note server crashes make this theoretically risky but practically rare.
  • WebSocket reconnection is generally handled by auto-reconnect on the client; some mention decoupling WS from business logic via a proxy layer.
  • Acks exist so the client knows the server has processed a move (not just received it via TCP/TLS).
  • Debate over “beautiful monolith vs microservices”: Lichess is mostly a monolith with a few separated services for fault isolation, not a microservice mesh. Some argue FAANG-scale redundancy/multi-region is justified; others say FAANG hiring and architectural fashions overemphasize complexity.

Time control, latency & lag compensation

  • Strong criticism of chess.com’s timing: perceived as server-clock-based with poor latency handling, leading to lost games on time and flaky puzzle behavior.
  • Lichess is praised for latency handling and “lag compensation,” which adjusts clocks based on observed delay; some worry this can be gamed by clients lying about timestamps.
  • Discussion of whether timing should be purely server-side vs client-measured-with-correction, referencing older systems like freechess.org’s “timeseal.”

Data formats & game state

  • Clarification that FEN encodes board state plus some counters, but not full game state (e.g., threefold repetition).
  • Lichess apparently stores move times with subsecond precision internally, but PGN exports still show 1-second resolution.

Perception of Lichess, moderation & community

  • Many call Lichess one of the best sites on the web and gladly donate; others push back that it has flaws.
  • A long subthread debates downvotes: one side sees them as silencing and even psychologically harmful; others see them as simple disagreement signals, distinct from moderation. Alternative moderation models (no votes, only flags + human mods) are proposed.

Technology choices & infra details

  • Server-side move generation is partly to keep the game-page JavaScript small and fast.
  • Redis is used mainly for pub/sub; ongoing game state is buffered in the main app.
  • Cost breakdown shows very low cost per game but single–data center dependence caused a 10‑hour outage; multi-region tradeoffs are discussed.
  • Scala/scalachess are cited as evidence Scala is alive and effective; there’s nuanced comparison with Rust on language features, ecosystem, and tooling.
  • For WebSocket DDoS protection, experiences with Cloudflare show added latency and frequent connection termination; advice is to rely on iptables, monitoring, and custom load-balancing infrastructure.

Miscellaneous

  • Clarifications around complexity: listing legal moves for a fixed-size chess board is not inherently “NP-hard”; confusion arises from mixing theoretical complexity with practical performance.
  • Various lighthearted comments play on the word “lichess,” and there are brief jokes about what “actually happens” when a move is made (usually: you lose a piece).