Überbuchungen, die niemand verhindern konnte.
Mehrere Strand-Venues auf einer gemeinsamen Tabelle zu betreiben ist kein Workflow-Problem. Es ist ein Datenkonsistenzproblem im Gewand eines Workflow-Problems. Zwei Manager öffnen dasselbe Blatt zur selben Zeit, springen zum selben Slot und drücken Speichern — einer von beiden gewinnt immer, und der andere weiß nie, dass er verloren hat. Der Betreiber entschädigte aus genau diesem Grund zwei- oder dreimal pro Woche unzufriedene Gäste.
Die PMS-Anbieter, die sie evaluiert hatten, verlangten allesamt einen On-Premise-Server, eine Lizenz pro Arbeitsplatz und ein dreimonatiges Onboarding. Nichts davon passte zu einem kleinen Betreiber mit Saisonpersonal, ohne IT-Funktion und mit einer starken Präferenz dafür, keine Infrastruktur zu besitzen. Das Briefing war klar: Wir wollen etwas, das unsere Manager im Browser öffnen können, und es soll nicht kaputtgehen.
Eine Reservierungskonsole für mehrere Objekte, mit Verfügbarkeitssynchronisation, die nicht pollt.
Die Konsole gab jedem Venue ein Live-Reservierungsraster — Anreisen, Abreisen, Verfügbarkeit pro Slot, Belegung pro Datum. Ein Manager an einem Objekt konnte gleichzeitige Änderungen von einem anderen Objekt in dem Moment sehen, in dem sie geschahen, ohne die Seite neu zu laden. Buchen, Ändern und Stornieren einer Reservierung aktualisierten den gemeinsamen Status sofort. Jede offene Session sah jede Änderung, sobald sie eintraf.
Unter der Konsole: Firestore für die Reservierungsdaten, Realtime Database für die Verfügbarkeitssynchronisationsschicht, Firebase Auth für das Session-Management und Firebase Hosting für die statische SPA. Kein Node-Server. Kein Express-Prozess, der neu zu starten wäre. Keine Deployment-Pipeline jenseits eines einzigen CLI-Befehls.
Die Analytics-Oberfläche lief neben der operativen: Gästedemografie, Buchungstrend-Diagramme über Highcharts und eine Umsatzprognose-Ansicht, gezogen aus denselben Firestore-Kollektionen, die das Reservierungsraster ohnehin las. Eingebaute Rechnungserzeugung (jsPDF) und CSV-/XLSX-Export wickelten den Monatsabschluss-Workflow des Eigentümers ohne ein separates Tool ab. Dreieinhalb Monate vom ersten Commit bis zur Produktion.
- F · 01Live-Verfügbarkeitssynchronisation
- Firestore + Realtime Database übertragen Updates an jede offene Session in dem Moment, in dem sich eine Buchung ändert. Kein Polling. Kein Neuladen.
- F · 02Dashboard für mehrere Objekte
- Eine Konsole umspannt alle Venues. Jedes Objekt erhält sein eigenes Raster; die Eigentümerin sieht das Gesamtbild in einem einzigen Tab.
- F · 03Firebase-Auth-Session-Schicht
- Firebase Auth verwaltet Sessions über Eigentümer-, Manager- und Mitarbeiternutzer hinweg. Kein eigener Auth-Server, keine zu pflegende Berechtigungstabelle. Rollenprüfungen auf Anwendungsebene sichern die Oberflächen ab.
- F · 04Rechnungserzeugung
- Buchungsbestätigungen und Rechnungen clientseitig mit jsPDF erzeugt und direkt per E-Mail versendet — kein separates Abrechnungstool.
- F · 05Massen-Import / -Export
- CSV- und XLSX-Import für saisonales Massen-Laden. Export für den Buchhalter des Eigentümers zum Monatsabschluss. Beides läuft im Browser.
- F · 06Analytics
- Gästedemografie, Buchungstrends und eine Umsatzprognose-Ansicht auf Basis von Highcharts, die dieselben Firestore-Kollektionen wie das Reservierungsraster liest.
Die reine Firebase-Entscheidung, und warum sie die Produktion überlebte.
Gleichzeitige Reservierungsversuche auf demselben Slot — zwei Manager buchen die letzte Strandliege des Nachmittags — waren genau der Fehler, für den der Betreiber immer wieder zahlte. Die Lösung war kein Locking auf der Schreibseite; es war Wahrheit auf der Leseseite. Die Echtzeit-Listener von Firestore bedeuteten, dass jede offene Session auf jedem Gerät eine Buchung in dem Augenblick sah, in dem sie geschrieben wurde. Sobald ein Slot belegt war, zeigte ihn der Bildschirm jedes Managers an. Das Koordinationsversagen der Tabelle — zwei Personen, die mit veralteten Ansichten derselben Zeile arbeiteten — konnte nicht eintreten, weil niemand mit einer veralteten Ansicht arbeitete.
Die Entscheidung, gänzlich auf einen Backend-Server zu verzichten, war keine kostensparende Abkürzung. Es war die richtige Architektur für die Zwänge dieses Betreibers. Es gab kein DevOps-Team, das einen Node-Prozess hüten würde, keine Bereitschaftsrotation, die man uns übergeben könnte, und keine Toleranz für einen Server, der an einem Samstag im August ausfällt. Die von Firebase verwalteten Dienste tragen die Verfügbarkeitsgarantie; wir tragen die Anwendungslogik. Die Grenze ist sauber.
Firebase Auth übernahm das Session-Management ohne einen eigenen Auth-Server. Die Mehrsprachenunterstützung für einen internationalen Gästestamm lief über ngx-translate. Das statische Bundle deployte in unter zwei Minuten auf Firebase Hosting. Die gesamten monatlichen Infrastrukturkosten lagen in den ersten sechs Produktionsmonaten innerhalb des kostenlosen Firebase-Kontingents.
Null Doppelbuchungen. Die Infrastrukturkosten blieben im kostenlosen Kontingent.
Das Überbuchungsproblem hörte auf. In den ersten zwölf Betriebsmonaten verzeichnete der Betreiber null kollidierende Reservierungen auf demselben Slot. Die Tabelle blieb eine Woche nach dem Launch geöffnet, als Rückfallebene, die niemand nutzte.
Das System ging über drei Objekte gleichzeitig live. Die Eigentümerin führte die Mitarbeiterschulung selbst durch, an einem einzigen Nachmittag, weil die Konsole einfach genug war, um sie in einer Sitzung zu erklären. Die Fluktuation des Saisonpersonals — der andere Grund, aus dem die Tabelle so fragil gewesen war — war kein Datenintegritätsrisiko mehr, sobald der Status in der Datenbank lebte und nicht in der lokalen Datei einer Person. Neue Saisonkräfte erhielten eine Firebase-Auth-Einladung und dieselbe Konsole, die alle anderen nutzten.
Das Produkt läuft seit 2019 ohne einen Backend-Server. Der Betreiber hat bei uns nie einen Bereitschafts-Page ausgelöst.
Wir haben aufgehört, Gäste zu entschädigen. Das ist die ganze Geschichte.