Engineering
Live-Scoring im großen Maßstab: was zwischen dem Tippen des Schiedsrichters und dem Bildschirm des Fans passiert
Auf Court acht in einer Schulturnhalle ohne Empfang fällt ein Punkt. Zwei Sekunden später steht er auf einem Smartphone in einem anderen Land. Das ist der Weg, den er nimmt.
Ein Ballwechsel endet auf Court acht. Der Schiedsrichter tippt einmal. Irgendwo zwischen einer und drei Sekunden später erscheint dieser Punkt auf dem Smartphone einer Großmutter, die aus einem anderen Land zuschaut, auf der öffentlichen Anzeigetafel des Turniers, im Turnierbaum, der nach dem Match weiterrückt, und in dem Datensatz, den die Analytik-Engine liest.
So beschrieben klingt es einfach. Es ist es nicht, weil Court acht in einer Schulturnhalle mit zwei Balken Empfang liegt, der Schiedsrichter ein Ehrenamtlicher ist, der die App zweimal benutzt hat, und dreiundzwanzig weitere Courts gleichzeitig dasselbe tun.
Regel eins: Das Tablet darf das Netz nicht brauchen
Die folgenreichste Architekturentscheidung beim Live-Scoring ist, was passiert, wenn die Verbindung ausfällt – denn an indischen Turnierstätten fällt sie ständig aus. Sporthallen sind Stahlrahmenkästen. Hallen füllen sich mit mehreren Hundert Menschen, die alle in derselben Funkzelle hängen. Das WLAN, das freitags beim Aufbau funktionierte, ist samstags um zehn Uhr unbrauchbar.
Also ist die Wertungs-App lokal maßgeblich. Ein Tippen erfasst den Punkt, aktualisiert den Zustand auf dem Bildschirm, wendet die Regeln der Sportart an – ist das Satzball, wechselt der Aufschlag, ist der Satz beendet – und schreibt ihn in eine lokale Warteschlange. All das geschieht mit oder ohne Netz, in wenigen Millisekunden, weil dabei nie etwas über die Leitung angefragt wird.
Die Warteschlange wird dann zum Server geleert, sobald es geht, in strenger Reihenfolge, wobei jedes Ereignis seine eigene Sequenznummer und seinen Zeitstempel trägt. Ein fünfminütiger Verbindungsausfall bedeutet fünf Minuten Verzögerung für die Zuschauer und exakt null Auswirkung auf das Match. Der Schiedsrichter sieht nie eine Ladeanimation, und der Spielstand stimmt immer.
Regel zwei: Der Rechnung des Clients nie vertrauen
Das Tablet berechnet den Spielstand, damit der Schiedsrichter sofort eine Rückmeldung bekommt. Der Server berechnet ihn aus dem rohen Ereignisstrom neu, mit derselben Regel-Engine. Weichen beide voneinander ab, gewinnt der Server, und das Tablet wird korrigiert.
Das ist wichtig, weil Clients abdriften. Eine App, die sechs Stunden geöffnet war, zweimal im Hintergrund lief und bei der ein Ereignis in falscher Reihenfolge ankam, kann in einem Zustand enden, der plausibel aussieht und falsch ist. Die serverseitige Wiedergabe der Ereignisse sorgt dafür, dass der maßgebliche Spielstand immer eine reine Funktion dessen ist, was tatsächlich geschah – und dieselbe Wiedergabe ermöglicht es einem Schiedsrichter, einen Punkt von vor drei Ballwechseln zu korrigieren, ohne dass etwas Nachgelagertes durcheinandergerät. Die Korrektur ist nur ein weiteres Ereignis; alles danach wird neu berechnet.
Ein Ereignisstrom, viele Leser
Alles, was ein Zuschauer, ein Turnierbaum, ein Übertragungs-Overlay oder ein Analytikmodell sieht, wird aus demselben geordneten Ereignisstrom abgeleitet. Deshalb können sich der Turnierbaum auf der Auslosungsseite und der Spielstand auf der Live-Seite nie widersprechen – es sind nicht zwei Systeme, die synchronisiert werden, sondern zwei Projektionen eines einzigen Protokolls.
Regel drei: Auf dem Lesepfad liegt der Verkehr
Vierundzwanzig Courts, die alle dreißig Sekunden ein Ereignis erzeugen, sind eine triviale Schreiblast – etwa ein Schreibzugriff pro Sekunde über ein ganzes Turnier. Die Leseseite ist ein völlig anderes Problem. Bei einem beliebten Finale können Tausende Menschen gleichzeitig dasselbe Match abfragen, und jeder erwartet, dass die Zahl aktuell ist.
Lesezugriffe werden aus einem Cache bedient, den der Ereignisstrom beim Schreiben ungültig macht, sodass die Anfrage eines Zuschauers fast nie die Datenbank erreicht. Deshalb ist das Lastprofil eines Turniers so schief und zugleich so gut beherrschbar: Teuer ist nicht die Sportart, sondern das Publikum – und das Publikum fragt nach genau denselben paar Zahlen.
Regel vier: Die Schiedsrichter-Oberfläche ist das ganze Produkt
Nichts davon spielt eine Rolle, wenn die Ehrenamtliche oder der Ehrenamtliche am Spielfeldrand die App unter Druck nicht bedienen kann.
Der Wertungsbildschirm jeder Sportart zeigt die kleinste Menge an Bedienelementen, die diese Sportart braucht, und sonst nichts. Badminton sind zwei große Punkttasten und eine Aufschlaganzeige. Ringen braucht Punktwerte, Verwarnungen und einen Schultersieg. Basketball braucht eine Uhr. Sportartspezifische Oberflächen statt einer konfigurierbaren sind mehr Arbeit, und es ist alles andere als verhandelbar – eine generische Oberfläche heißt, dass eine Ehrenamtliche nach dem richtigen Bedienelement sucht, während ein Match wartet.
- Bedienelemente, dimensioniert für einen Daumen auf einem schräg gehaltenen Tablet, in einer Halle mit schlechtem Licht.
- Ein Rückgängig-machen, das mit einem Tippen geht und immer verfügbar ist – denn die Korrektur einer Fehleingabe muss schneller sein als die Fehleingabe.
- Ein Zustand, der übersteht, dass die App beendet wird, das Tablet ausfällt oder mitten im Match der Schiedsrichter wechselt.
- Keine modalen Dialoge während eines Ballwechsels. Niemals.
Was das zusammen ergibt
Rund 150.000 Matches sind inzwischen durch diese Pipeline gelaufen. Das Maß, das uns interessiert, ist nicht Durchsatz oder Latenz – beides ist komfortabel. Es ist, dass in dieser Zeit die Zahl der Matches, bei denen das veröffentlichte Ergebnis korrigiert werden musste, weil das System einen Spielstand verloren oder verfälscht hat, genau die Zahl ist, die ein amtliches Protokoll für sich beanspruchen muss: null.
