Die Lücke zwischen zwei Kanälen schließt nicht Geschwindigkeit, sondern ein einziger Verfügbarkeitspool, aus dem jeder Kanal liest — statt mehrerer Kopien, die sich jeweils selbst glauben.
Fast keine Doppelbuchung entsteht durch ein langsames System. Sie entsteht, weil dasselbe Zimmer an mehreren Stellen gleichzeitig erfasst wird und jede Stelle ihrer eigenen Kopie vertraut. Solange die Wahrheit in mehr als einer Version existiert, gibt es immer einen Moment, in dem zwei Versionen sich widersprechen — Geschwindigkeit macht diesen Moment nur kürzer, nie unmöglich.
Stellen Sie sich das letzte Zimmer für eine Samstagnacht vor, gelistet auf zwei Kanälen. Zwei Gäste buchen innerhalb von Sekunden. Jeder Kanal prüft seine eigene Kopie der Verfügbarkeit, sieht das Zimmer als frei und nimmt die Buchung an. Bis die Schließanweisung den zweiten Kanal erreicht, existiert die zweite Reservierung bereits.
Niemand hat einen Fehler gemacht. Beide Kanäle verhielten sich genau wie vorgesehen. Der Fehler liegt in der Architektur: Beiden Systemen wurde erlaubt zu glauben, sie besäßen dasselbe Zimmer.
Kalender per iCal zu verknüpfen ist der häufigste erste Schritt und durchaus vernünftig. Aber iCal ist ein Pull-Format: Die andere Seite ruft Ihre Kalenderdatei nach eigenem Zeitplan ab, typischerweise im Abstand von zehn bis zwanzig Minuten, manchmal länger, wenn die Plattform stark ausgelastet ist. Nichts daran ist sofort, und nichts daran ist garantiert.
Der Wechsel von iCal zu einer echten Verbindung verkürzt das Zeitfenster drastisch, von Minuten auf Sekunden. Das ist eine echte Verbesserung und beseitigt die meisten Vorfälle. Aber es beseitigt nicht die Ursache, denn ein push-basiertes Design bedeutet immer noch, dass mehrere Kopien existieren und erst nachträglich abgeglichen werden.
Es gibt auch einen subtileren Fehler, den Geschwindigkeit nicht beheben kann. Manche Kanäle nehmen eigene automatische Anpassungen an der Verfügbarkeit vor — etwa ein Zimmer wieder freigeben, wenn eine Stornierung eingeht. Schreibt Ihr System im selben Moment eine absolute Zahl, während der Kanal seine eigene Änderung anwendet, können beide Vorgänge in beliebiger Reihenfolge landen — manchmal mit einem Ergebnis, das höher ist als die Wahrheit.
Die strukturelle Lösung ist, keine Kopien mehr zu führen. Verfügbarkeit wird aus einem einzigen Pool echter Zimmer berechnet, und jeder Kanal ist nur eine Ansicht auf diesen Pool, nicht Besitzer eines Teils davon. Trifft eine Reservierung von irgendwoher ein, schrumpft der Pool, und jeder Kanal wird auf die neue Zahl korrigiert.
Dieser letzte Punkt ist wichtiger, als er scheint. Ein System, das den aktuellen Zustand eines Kanals nicht lesen kann, hat zwei Optionen: raten oder es zugeben. Zu raten in Richtung „wahrscheinlich noch verfügbar“ ist genau der Weg, auf dem ein Zimmer zweimal verkauft wird. Sich zu weigern zu raten, macht den Unterschied zwischen einem System, das meistens richtig liegt, und einem, auf das Sie sich bei vollem Haus wirklich verlassen können.