De kloof tussen twee kanalen wordt niet gedicht door snelheid. Die wordt gedicht door één beschikbaarheidspool waaruit elk kanaal leest, in plaats van meerdere kopieën die elk zichzelf geloven.
Bijna geen dubbele boeking wordt veroorzaakt door een traag systeem. Ze ontstaan omdat dezelfde kamer op meerdere plaatsen tegelijk is vastgelegd, waarbij elke plaats zijn eigen kopie vertrouwt. Zolang de waarheid in meer dan één versie bestaat, is er altijd een moment waarop twee versies elkaar tegenspreken — en snelheid maakt dat moment alleen korter, nooit afwezig.
Stel u de laatste vrije kamer voor een zaterdagnacht voor, vermeld op twee kanalen. Twee gasten boeken binnen enkele seconden van elkaar. Elk kanaal controleert zijn eigen kopie van de beschikbaarheid, ziet de kamer als vrij en accepteert de boeking. Tegen de tijd dat de sluitingsopdracht het tweede kanaal bereikt, bestaat de tweede reservering al.
Niemand heeft een fout gemaakt. Beide kanalen gedroegen zich precies zoals ontworpen. De storing is architectonisch: twee systemen mochten elk geloven dat ze dezelfde kamer bezaten.
Kalenders koppelen met iCal is de meest gebruikelijke eerste stap, en een redelijke. Maar iCal is een pull-gebaseerd formaat: de andere kant haalt uw kalenderbestand op volgens zijn eigen schema, meestal gemeten in tientallen minuten, en soms langer wanneer het platform druk is. Niets hieraan is instant, en niets hieraan is gegarandeerd.
De overstap van iCal naar een echte verbinding verkort dat venster drastisch, van minuten naar seconden. Dat is een echte verbetering en het verwijdert de meeste incidenten. Maar het verwijdert de categorie niet, omdat een push-gebaseerd ontwerp nog steeds betekent dat er meerdere kopieën bestaan die achteraf worden verzoend.
Er is ook een subtielere storing die snelheid niet raakt. Sommige kanalen passen hun eigen automatische aanpassingen toe op beschikbaarheid — bijvoorbeeld een kamer teruggeven bij een annulering. Als uw systeem op precies hetzelfde moment een absoluut aantal schrijft terwijl het kanaal zijn eigen delta toepast, kunnen de twee bewerkingen in elke volgorde terechtkomen, en is het resultaat soms hoger dan de waarheid.
De structurele oplossing is stoppen met het bijhouden van kopieën. Beschikbaarheid wordt berekend uit één pool van echte kamers, en elk kanaal is een weergave van die pool in plaats van eigenaar van een deel ervan. Wanneer een reservering van waar dan ook binnenkomt, krimpt de pool, en elk kanaal wordt gecorrigeerd naar het nieuwe aantal.
Dat laatste punt is belangrijker dan het lijkt. Een systeem dat de huidige status van een kanaal niet kan uitlezen, heeft twee opties: gokken of het zeggen. Gokken in de richting van „waarschijnlijk nog beschikbaar” is precies hoe een kamer twee keer wordt verkocht. Niet gokken is wat het verschil maakt tussen een systeem dat meestal gelijk heeft en een systeem waarop u echt kunt rekenen tijdens een volledig volgeboekt huis.