Le score en direct à grande échelle : ce qui se passe entre le geste de l’arbitre et l’écran du fan

Un échange se termine sur le court huit. L’arbitre appuie une fois. Entre une et trois secondes plus tard, ce point apparaît sur le téléphone d’un grand-parent qui regarde depuis un autre pays, sur le tableau d’affichage public du tournoi, sur le tableau qui avancera à la fin du match, et dans le jeu de données que lit le moteur d’analyse.

Décrit ainsi, cela paraît simple. Ce qui ne l’est pas, c’est que le court huit se trouve dans un gymnase scolaire avec deux barres de réseau, que l’arbitre est un bénévole qui a utilisé l’application deux fois, et que vingt-trois autres courts font la même chose en même temps.

Règle un : la tablette ne doit pas avoir besoin du réseau

La décision d’architecture la plus lourde de conséquences en score en direct est ce qui se passe quand la connectivité tombe, car dans les lieux de tournoi indiens, elle tombe en permanence. Les gymnases sont des boîtes à ossature métallique. Les salles se remplissent de plusieurs centaines de personnes sur la même antenne. Le Wi-Fi qui fonctionnait lors de l’installation le vendredi est inutilisable dès 10 h le samedi.

L’application de score fait donc autorité localement. Une pression enregistre le point, met à jour l’état à l’écran, applique les règles du sport — est-ce une balle de manche, le service change-t-il, la manche est-elle terminée — et l’écrit dans une file locale. Tout cela se produit avec ou sans réseau, en quelques millisecondes, car rien n’est demandé sur le réseau.

La file se vide ensuite vers le serveur dès que possible, dans un ordre strict, chaque événement portant son propre numéro de séquence et son horodatage. Une coupure de cinq minutes produit cinq minutes de retard pour les spectateurs et un impact rigoureusement nul sur le match. L’arbitre ne voit jamais de roue de chargement, et le score n’est jamais faux.

Règle deux : ne jamais se fier au calcul du client

La tablette calcule le score pour que l’arbitre obtienne une réponse instantanée. Le serveur le recalcule, à partir du flux d’événements brut, avec le même moteur de règles. Si les deux divergent, le serveur l’emporte et la tablette est corrigée.

C’est important car les clients dérivent. Une application ouverte depuis six heures, passée deux fois en arrière-plan et qui a reçu un événement dans le désordre peut aboutir à un état qui paraît plausible et qui est faux. Rejouer les événements côté serveur garantit que le score faisant autorité est toujours une fonction pure de ce qui s’est réellement passé, et c’est ce même rejeu qui permet à un arbitre de corriger un point d’il y a trois échanges sans que rien en aval ne s’y perde. La correction n’est qu’un événement de plus ; tout ce qui suit est recalculé.

Règle trois : c’est la lecture qui concentre le trafic

Vingt-quatre courts produisant un événement toutes les trente secondes représentent une charge d’écriture dérisoire — environ une écriture par seconde sur tout un tournoi. Le côté lecture est un tout autre problème. Une finale très suivie peut avoir des milliers de personnes qui interrogent simultanément le même match, et chacune s’attend à un chiffre à jour.

Les lectures sont servies depuis un cache que le flux d’événements invalide à l’écriture, si bien que la requête d’un spectateur n’atteint presque jamais la base de données. C’est pourquoi le profil de trafic d’un tournoi est si déséquilibré et si maîtrisable : ce qui coûte cher, ce n’est pas le sport, c’est le public, et le public demande tout entier exactement les mêmes quelques chiffres.

Règle quatre : l’interface de l’arbitre est tout le produit

Rien de tout cela ne compte si le bénévole au bord du court ne peut pas utiliser l’application sous pression.

L’écran de score de chaque sport affiche le plus petit ensemble de commandes dont ce sport a besoin, et rien d’autre. Le badminton, ce sont deux gros boutons de score et un indicateur de service. La lutte exige des valeurs de points, des avertissements et un tomber. Le basket-ball exige un chrono. Construire des interfaces propres à chaque sport plutôt qu’un écran configurable demande plus de travail, et ce n’est absolument pas négociable — une interface générique oblige un bénévole à chercher la bonne commande pendant qu’un match attend.

• Des cibles dimensionnées pour un pouce sur une tablette tenue de biais, dans une salle mal éclairée.
• Une annulation en une seule pression et toujours disponible, car la correction d’une fausse manipulation doit être plus rapide que la fausse manipulation.
• Un état qui survit à l’arrêt brutal de l’application, à la panne de la tablette ou au remplacement de l’arbitre en cours de match.
• Aucune boîte de dialogue modale pendant un échange. Jamais.

Ce que cela donne au total

Environ 150 000 matchs sont désormais passés par cette chaîne. La mesure qui nous importe n’est ni le débit ni la latence — tous deux sont confortables. C’est que, sur cette période, le nombre de matchs dont le résultat publié a dû être corrigé parce que le système avait perdu ou altéré un score est celui qu’un registre officiel doit pouvoir revendiquer : zéro.