Die große Baustelle: schlüsselkartenfreier Einlass

Foto: snehgohil · WordPress Photos (CC0 1.0), via Openverse

Es gibt Wochen, in denen man ein Feature abschließt, und es gibt Wochen, in denen man eine ganze Kategorie eröffnet. Diese war das Zweite. Bis vor Kurzem war Xircuit eine Plattform, die weiß, wer Mitglied ist, was jemand gebucht hat und wie es um dessen Trainingsfortschritt steht — aber sie hatte keinerlei Kontrolle über die physische Tür, durch die dieselbe Person morgens ins Studio geht. Genau diese Lücke war die größte Baustelle, die ich mir bisher vorgenommen habe.

Der Gedanke dahinter ist simpel, die Umsetzung war es nicht: Wer ein aktives Abo hat, soll ohne Plastikkarte, ohne Chip und ohne Anstehen an der Theke ins Gebäude kommen. Die Mitgliedschaft selbst wird zum Schlüssel. Das klingt nach einer kleinen Erweiterung, ist in Wirklichkeit aber die Stelle, an der Software zum ersten Mal auf ein Stück Hardware trifft, das eine Tür entriegelt — und das verzeiht keine ungefähren Antworten.

Warum schlüsselkartenfrei überhaupt eine eigene Baustelle ist

Kartensysteme sind seit Jahrzehnten Standard, und genau das ist ihr Problem: Sie kennen keinen Zustand. Eine Karte, die einmal ausgegeben wurde, öffnet die Tür so lange, bis sie physisch gesperrt oder eingesammelt wird. Läuft ein Abo aus, wird eine Kündigung wirksam oder wird ein Zugang aus disziplinarischen Gründen entzogen, hängt die Durchsetzung an einem manuellen Schritt an der Rezeption. Zwischen „im System gekündigt" und „kommt nicht mehr rein" liegen im schlimmsten Fall Tage.

Kontaktloser, schlüsselkartenfreier Einlass dreht das um. Die Entscheidung, ob jemand hereindarf, fällt nicht mehr auf einem Stück Plastik, sondern in dem Moment, in dem die Person vor der Tür steht. Die Plattform prüft in Echtzeit, ob die Mitgliedschaft in diesem Augenblick gültig ist, und gibt die Tür nur dann frei. Ein Abo, das um Mitternacht endet, öffnet um 6:01 Uhr nichts mehr — ohne dass jemand eingreifen muss. Das ist der eigentliche Wert, und es ist auch der Grund, warum die ganze Sache so tief in die Architektur greift: Eine Zugangsentscheidung darf weder zu langsam noch falsch sein.

Echtzeit an der Tür: das erste SignalR-Backplane

Der technisch spannendste Teil war die Echtzeit-Kette. Wenn jemand vor der Tür steht, darf die Prüfung nicht gefühlt eine Sekunde brauchen und schon gar nicht davon abhängen, dass ein Hintergrund-Poller irgendwann einmal den passenden Datensatz durchsieht. Türereignisse müssen fließen, in dem Moment, in dem sie entstehen — der Vorgang an der Tür, die Prüfung im Backend, die Freigabe zurück an die Hardware.

Dafür kam zum ersten Mal in Xircuit ein Azure-SignalR-Backplane zum Einsatz. Bisher lief SignalR, wo überhaupt, prozessintern; ein Backplane brauchte die Plattform nie, weil kein Feature mehrere Instanzen über einen gemeinsamen Echtzeit-Bus koordinieren musste. Die Zugangskontrolle ändert das: Türereignisse können auf jeder beliebigen Replica ankommen, und die Antwort muss verlässlich wieder bei genau der Verbindung landen, an der die betroffene Tür hängt. Das Backplane ist der Klebstoff, der das über mehrere Container-Instanzen hinweg zusammenhält. In einer horizontal skalierten Aspire-Welt ist das keine Kür, sondern Voraussetzung dafür, dass Echtzeit auch unter Last Echtzeit bleibt.

Zonen und automatische Sperrung

Ein Studio ist selten ein einziger Raum mit einer einzigen Tür. Es gibt den Haupteingang, vielleicht einen separaten Kursraum, einen Wellnessbereich, Umkleiden, gelegentlich eine 24/7-Zone, die nur bestimmten Tarifen offensteht. Genau dafür gibt es die Zonenverwaltung: Sie regelt, wer wann wohin darf. Eine Mitgliedschaft ist damit nicht mehr nur „gültig" oder „ungültig", sondern an konkrete Bereiche und Zeitfenster geknüpft.

Die Kehrseite der Freigabe ist die automatische Sperrung. Wenn eine Zone außerhalb ihrer Öffnungszeiten liegt, wenn ein Abo nicht die passende Berechtigung trägt oder wenn ein Zugang aktiv entzogen wurde, bleibt die Tür geschlossen — ohne dass jemand eine Karte kassieren muss. Diese beiden Hälften, Zugang und Sperrung, sind bewusst dieselbe Entscheidung aus zwei Richtungen betrachtet. Es gibt keinen zweiten Codepfad, der „verbieten" anders behandelt als „erlauben"; es ist eine einzige Prüfung, deren Ergebnis in die eine oder die andere Richtung fällt. Das macht das Verhalten vorhersehbar und die Regeln nachvollziehbar.

Foto: Mike Wilson · StockSnap (CC0 1.0), via Openverse

Zehn Teilschritte, fünfzehn Dienste, ein eigener Worker

Ich will nicht so tun, als wäre das ein Wochenendprojekt gewesen. Es war die mit Abstand umfangreichste Ausbaustufe der Plattform bisher: zehn Teilschritte von der ersten Datenmodellierung bis zur lauffähigen Türfreigabe, und am Ende zählte die Slice fünfzehn Dienste, die zusammenspielen müssen. Das reicht von der API, die Zugangsentscheidungen ausspricht, über die SignalR-Schicht bis zu den Diensten, die Zonen, Berechtigungen und Türzustände verwalten.

Herzstück ist ein eigener Access-Control-Worker. Die Zugangslogik gehört bewusst nicht in den Web-Host, der Seiten rendert, und auch nicht in einen der bestehenden Fachworker. Türentscheidungen und Türereignisse haben ein anderes Zeit- und Fehlerprofil als alles andere in der Plattform: Sie sind latenzkritisch, sie dürfen nicht mit einem langsamen Report-Lauf um dieselben Ressourcen konkurrieren, und sie brauchen eine klare, isolierte Zuständigkeit. Deshalb bekam die Zugangskontrolle ihren eigenen Prozess — ganz in der Linie der übrigen Integrations- und Worker-Struktur, in der jeder klar umrissene Fachbereich seinen eigenen Dienst erhält. Dass es fünfzehn Dienste geworden sind, ist kein Selbstzweck, sondern die ehrliche Folge davon, dass hier eine physische Domäne sauber von der digitalen getrennt bleiben muss.

Gantner-Hardware und die Grenze zwischen Software und Tür

Software allein öffnet keine Tür. Für den physischen Teil setzt Xircuit auf Hardware von Gantner — Beschläge und Leser, die im Fitness- und Zutrittsbereich etabliert sind und die eigentliche mechanische Freigabe übernehmen. Meine Aufgabe war nicht, ein Türschloss zu erfinden, sondern die Brücke zwischen der Echtzeit-Entscheidung der Plattform und dem, was Gantner an der Wand tut, verlässlich zu bauen.

Diese Grenze ist auch die interessanteste Stelle für die kommenden Wochen. Zwischen der Cloud-Entscheidung und dem Gantner-Beschlag liegt am Ende immer ein Stück, das vor Ort im Studio läuft — und dieses Stück muss man mit besonderer Vorsicht behandeln, weil es an Hardware klebt und nicht mal eben neu deployt werden kann. Für diese Woche galt: Die Kette steht auf dem Papier und im Code, die echte Tür ist der nächste Schritt.

Verwaltbar, aber hinter einem Flag

So groß eine solche Slice ist, so wichtig ist es, sie kontrolliert einzuführen. Die gesamte Zugangskontrolle läuft daher hinter dem Feature-Flag Features:AccessControl und ist damit standardmäßig aus. Kein Studio bekommt ungefragt eine scharfgeschaltete Türsteuerung; die Funktion wird erst dort aktiv, wo sie bewusst eingeschaltet und verifiziert wurde. Das ist die einzige verantwortbare Art, ein Feature auszurollen, das im Ernstfall darüber entscheidet, ob jemand vor einer verschlossenen Tür steht.

Für die Einrichtung gibt es eine Reihe von Verwaltungswerkzeugen in Form von Set-*.ps1-Skripten, die Türen und Zonen konfigurieren. Statt jede Tür von Hand über verstreute Datenbankeinträge anzulegen, geht die Konfiguration über nachvollziehbare, wiederholbare Skripte — dasselbe Muster, das sich schon bei den Geheimnis- und Einrichtungswerkzeugen der übrigen Plattform bewährt hat. Wer eine neue Zone anlegt oder eine Tür zuordnet, tut das über ein Skript, dessen Ergebnis reproduzierbar ist, und nicht über einen manuellen Klickpfad, den beim nächsten Mal niemand mehr rekonstruieren kann.

Was kommt als Nächstes?

Nächste Woche: der On-Device-Connector, der die Türen anbindet — und wie wir sein Auto-Update sicher machen. Genau an der Grenze zwischen Cloud und Beschlag, über die ich oben geschrieben habe, entscheidet sich, ob aus einer sauberen Architektur auch ein zuverlässig entriegelndes Schloss wird.