Puntuación en vivo a gran escala: lo que ocurre entre el toque del árbitro y la pantalla del aficionado

Termina un peloteo en la pista ocho. El árbitro toca una vez. Entre uno y tres segundos después, ese punto aparece en el móvil de un abuelo que mira desde otro país, en el marcador público del torneo, en el cuadro que avanzará cuando termine el partido y en el conjunto de datos que lee el motor de analítica.

Contado así parece sencillo. No lo es porque la pista ocho está en un gimnasio escolar con dos rayas de cobertura, el árbitro es un voluntario que ha usado la app dos veces y hay otras veintitrés pistas haciendo lo mismo al mismo tiempo.

Regla uno: la tableta no debe necesitar la red

La decisión arquitectónica más trascendente en la puntuación en vivo es qué ocurre cuando falla la conectividad, porque en los recintos de torneos de la India la conectividad falla constantemente. Los gimnasios son cajas con estructura de acero. Los pabellones se llenan con varios cientos de personas conectadas a la misma celda. El wifi que funcionaba durante la preparación del viernes es inservible a las 10 del sábado.

Así que la app de puntuación es la autoridad a nivel local. Un toque registra el punto, actualiza el estado en pantalla, aplica las reglas del deporte (¿es punto de set?, ¿cambia el saque?, ¿ha terminado el set?) y lo escribe en una cola local. Todo eso ocurre haya red o no, en pocos milisegundos, porque nunca pregunta nada por la red.

Después la cola se vuelca al servidor cuando puede, en estricto orden, con cada evento llevando su propio número de secuencia y marca de tiempo. Un corte de conectividad de cinco minutos produce un retraso de cinco minutos para los espectadores y un impacto exactamente nulo en el partido. El árbitro nunca ve una rueda de carga y el marcador nunca es erróneo.

Regla dos: no confiar nunca en la aritmética del cliente

La tableta calcula el marcador para que el árbitro reciba una respuesta instantánea. El servidor lo recalcula a partir del flujo de eventos en bruto, con el mismo motor de reglas. Si ambos discrepan, gana el servidor y se corrige la tableta.

Esto importa porque los clientes se desvían. Una app abierta durante seis horas, enviada dos veces a segundo plano y con un evento entregado fuera de orden puede acabar en un estado que parece plausible y es erróneo. Reproducir los eventos en el servidor hace que el marcador oficial sea siempre una función pura de lo que realmente ocurrió, y esa misma reproducción es lo que permite a un árbitro corregir un punto de hace tres peloteos sin que nada posterior se confunda. La corrección es simplemente otro evento; todo lo que viene después se recalcula.

Regla tres: el camino de lectura es donde está el tráfico

Veinticuatro pistas que producen un evento cada treinta segundos son una carga de escritura trivial: aproximadamente una escritura por segundo en todo un torneo. El lado de la lectura es un problema completamente distinto. Una final muy seguida puede tener a miles de personas consultando el mismo partido a la vez, y todas esperan que la cifra esté al día.

Las lecturas se sirven desde una caché que el flujo de eventos invalida al escribir, de modo que la petición de un espectador casi nunca llega a la base de datos. Por eso el perfil de tráfico de un torneo está tan desequilibrado y es tan manejable: lo costoso no es el deporte, sino el público, y todo el público pide exactamente las mismas pocas cifras.

Regla cuatro: la interfaz del árbitro es todo el producto

Nada de lo anterior importa si el voluntario junto a la pista no puede usar la app bajo presión.

La pantalla de puntuación de cada deporte muestra el conjunto mínimo de controles que ese deporte necesita y nada más. El bádminton son dos grandes botones de puntuación y un indicador de saque. La lucha necesita valores de puntos, amonestaciones y un tuché. El baloncesto necesita un reloj. Construir interfaces específicas por deporte en lugar de una sola pantalla configurable da más trabajo y no es negociable: una interfaz genérica supone un voluntario buscando el control adecuado mientras un partido espera.

• Botones dimensionados para un pulgar en una tableta sostenida en ángulo, en un pabellón con mala iluminación.
• Deshacer con un solo toque y siempre disponible, porque la solución a un toque erróneo tiene que ser más rápida que el toque erróneo.
• Un estado que sobrevive a que se cierre la app, se apague la tableta o se cambie de árbitro en mitad del partido.
• Sin cuadros de diálogo modales durante un peloteo. Nunca.

En qué se traduce todo esto

Unos 150 000 partidos han pasado ya por este flujo. La medida que nos importa no es el rendimiento ni la latencia, ambos holgados. Es que, en todo ese tiempo, el número de partidos en los que hubo que corregir el resultado publicado porque el sistema perdió o alteró un marcador es el que un registro oficial debe poder afirmar: cero.