Xadrez online (matchmaking e estado em tempo real)

01 · CONTEXTO

O que uma plataforma de xadrez precisa fazer

Uma plataforma de xadrez online faz três coisas: encontra um oponente de nível parecido, hospeda uma partida em tempo real com um relógio para cada jogador e mantém um ranking global de notas. Isso envolve comunicação em tempo real entre navegador e servidor.

O ponto que organiza o desenho aparece logo no enunciado da fonte: o servidor valida todo lance e é dono dos dois relógios, de modo que o jogador não pode dizer que um lance ilegal é válido nem que ainda tem mais tempo.

02 · REQUISITOS E ESCALA

Um formato só e números de referência

O enunciado fixa um único formato, o blitz de três minutos: cada jogador tem três minutos no total e o relógio dele só corre no próprio turno. Com isso, todas as partidas seguem as mesmas regras de matchmaking e de relógio.

Os requisitos centrais são três: achar um oponente por matchmaking baseado em nível e iniciar a partida; jogar em tempo real; e ver o ranking global e a própria posição, com atualização pouco depois de cada partida terminar.

A escala de referência é de 10 milhões de jogadores registrados e 500 mil partidas simultâneas no pico. Como cada partida tem dois jogadores, cada um em sua conexão, são 1 milhão de conexões simultâneas, além da capacidade de validar cada lance e rodar dois relógios por partida.

03 · DESENHO BASE

Primeiro, uma partida só

A fonte propõe construir primeiro uma única partida e só depois atacar, nos aprofundamentos, as partes que ficam difíceis em escala. Este diagrama didático segue essa ordem.

1. O navegador envia cada lance ao servidor de partida. O desenho tem um único servidor para focar no fluxo de uma partida.

2. O servidor de partida valida o lance e é dono dos dois relógios: o jogador não pode afirmar que um lance ilegal é válido nem que tem mais tempo.

3. O relógio de cada jogador corre só durante o turno dele, e quem o controla é o servidor, não o navegador.

4. Ao final da partida, o servidor grava o resultado no banco, de onde saem as notas e o ranking.

04 · APROFUNDAMENTOS

Onde o problema fica difícil

Segundo a fonte, as partes que ficam difíceis em escala são o matchmaking, a frota de servidores de jogo, o relógio justo sob latências diferentes e a leitura rápida do ranking.

05 · REFERÊNCIA REAL

O que o Lichess documenta

O README do Lichess descreve parte da arquitetura. As conexões WebSocket ficam em um servidor separado, que se comunica por Redis; a lógica pura de xadrez fica em um submódulo próprio; e as partidas ficam em MongoDB, indexadas por Elasticsearch, somando mais de 12 bilhões.

1. As conexões em tempo real passam por um balanceador e chegam a servidores só de conexão, separados da lógica de jogo, como no Lichess.

2. O servidor de conexões conversa com o resto do sistema por um canal em Redis, como descreve o README do Lichess.

3. O pedido de partida segue para o matchmaking, que procura um oponente de nível parecido e aciona um servidor de partida.

4. Durante a partida, o servidor de partida valida cada lance e controla os relógios, recebendo e devolvendo mensagens pelo canal de Redis.

5. Quando a partida termina, o resultado vai para uma fila e um consumidor atualiza as notas e o ranking, o que permite que o ranking mude pouco depois do fim das partidas.

6. As consultas ao ranking leem de um cache dedicado, em vez de ir ao banco a cada pedido.

As notas no Lichess usam o método Glicko-2. A documentação também registra duas regras: partidas perdidas por lag ou desconexão não devolvem pontos, mas, quando o próprio Lichess reinicia e alguém perde no tempo por isso, a partida é abortada.