Placar ao vivo em escala: o que acontece entre o toque do árbitro e a tela do torcedor

Um rali termina na quadra oito. O árbitro toca uma vez. Entre um e três segundos depois, esse ponto aparece no celular de um avô que assiste de outro país, no placar público do torneio, na chave que vai avançar quando a partida terminar e no conjunto de dados que o mecanismo de analytics lê.

Descrito assim, parece simples. O motivo de não ser é que a quadra oito fica em um ginásio escolar com duas barrinhas de sinal, o árbitro é um voluntário que usou o app duas vezes e há outras vinte e três quadras fazendo a mesma coisa ao mesmo tempo.

Regra um: o tablet não pode depender da rede

A decisão arquitetônica mais importante no placar ao vivo é o que acontece quando a conexão falha, porque nos locais de torneio na Índia a conexão falha o tempo todo. Ginásios são caixas de estrutura metálica. Os salões se enchem de centenas de pessoas na mesma antena. O Wi-Fi que funcionava na montagem de sexta já não serve às 10h de sábado.

Por isso o app de pontuação tem autoridade local. Um toque registra o ponto, atualiza o estado na tela, aplica as regras do esporte — é game point, o saque muda, o set terminou — e grava tudo em uma fila local. Tudo isso acontece com ou sem rede, em poucos milissegundos, porque nunca pergunta nada a ninguém pela conexão.

A fila então é descarregada no servidor assim que possível, em ordem estrita, com cada evento carregando seu próprio número de sequência e horário. Uma queda de conexão de cinco minutos gera cinco minutos de atraso para os espectadores e impacto exatamente zero na partida. O árbitro nunca vê um ícone de carregamento e o placar nunca fica errado.

Regra dois: nunca confiar na aritmética do cliente

O tablet calcula o placar para que o árbitro tenha resposta instantânea. O servidor o recalcula a partir do fluxo bruto de eventos, usando o mesmo mecanismo de regras. Se os dois divergirem, o servidor prevalece e o tablet é corrigido.

Isso importa porque os clientes se desviam. Um app aberto há seis horas, colocado em segundo plano duas vezes e que recebeu um evento fora de ordem pode acabar num estado que parece plausível e está errado. Reproduzir os eventos no servidor faz com que o placar oficial seja sempre uma função pura do que realmente aconteceu, e essa mesma reprodução é o que permite ao árbitro corrigir um ponto de três ralis atrás sem confundir nada adiante. A correção é só mais um evento; tudo o que vem depois é recalculado.

Regra três: o caminho de leitura é onde está o tráfego

Vinte e quatro quadras gerando um evento a cada trinta segundos é uma carga de gravação trivial — cerca de uma gravação por segundo em um torneio inteiro. O lado da leitura é um problema completamente diferente. Uma final muito disputada pode ter milhares de pessoas consultando a mesma partida ao mesmo tempo, e todas esperam que o número esteja atualizado.

As leituras são atendidas por um cache que o fluxo de eventos invalida a cada gravação, de modo que a requisição de um espectador quase nunca chega ao banco de dados. É por isso que o perfil de tráfego de um torneio é tão desequilibrado e, ao mesmo tempo, tão administrável: o que custa caro não é o esporte, é o público, e o público inteiro pede exatamente os mesmos poucos números.

Regra quatro: a interface do árbitro é o produto inteiro

Nada disso importa se o voluntário à beira da quadra não conseguir usar o app sob pressão.

A tela de pontuação de cada esporte mostra o menor conjunto de controles de que aquele esporte precisa, e nada além. O badminton tem dois botões grandes de pontuação e um indicador de saque. O wrestling precisa de valores de pontos, advertências e pin. O basquete precisa de um cronômetro. Construir interfaces específicas para cada esporte, em vez de uma tela configurável, dá mais trabalho e não é nem de longe negociável — uma interface genérica significa um voluntário procurando o controle certo enquanto a partida espera.

• Alvos de toque dimensionados para um polegar, num tablet segurado em ângulo, num ginásio com iluminação ruim.
• Um desfazer que exige um único toque e está sempre disponível, porque a correção de um toque errado precisa ser mais rápida que o toque errado.
• Um estado que sobrevive a o app ser encerrado, o tablet apagar ou o árbitro ser trocado no meio da partida.
• Nada de janelas modais durante um rali. Nunca.

No que isso resulta

Cerca de 150.000 partidas já passaram por esse pipeline. A medida que nos importa não é vazão nem latência — ambas estão confortáveis. É que, nesse tempo, o número de partidas em que o resultado publicado precisou ser corrigido porque o sistema perdeu ou deturpou um placar é o único que um registro oficial pode se dar ao luxo de declarar: zero.