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

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).