L'écart entre deux canaux ne se referme pas avec la vitesse. Il se referme avec un seul pool de disponibilité consulté par chaque canal, au lieu de plusieurs copies qui se croient chacune véridiques.
Presque aucune double réservation n'est causée par un système lent. Elle est causée par la même chambre enregistrée à plusieurs endroits à la fois, chaque endroit faisant confiance à sa propre copie. Tant que la vérité existe en plusieurs versions, il y a toujours un moment où deux versions se contredisent — et la vitesse ne fait que raccourcir ce moment, jamais le faire disparaître.
Imaginez la dernière chambre pour un samedi soir, publiée sur deux canaux. Deux clients réservent à quelques secondes d'intervalle. Chaque canal vérifie sa propre copie de la disponibilité, voit la chambre libre, et accepte. Au moment où l'instruction de fermeture atteint le second canal, la seconde réservation existe déjà.
Personne n'a fait d'erreur. Les deux canaux se sont comportés exactement comme prévu. L'échec est architectural : deux systèmes ont chacun été autorisés à croire qu'ils possédaient la même chambre.
Relier les calendriers avec iCal est la première étape la plus courante, et c'est une étape raisonnable. Mais iCal est un format basé sur l'extraction : l'autre côté récupère votre fichier calendrier selon son propre horaire, généralement de l'ordre de dizaines de minutes, et parfois plus quand la plateforme est chargée. Rien n'y est instantané, et rien n'y est garanti.
Passer d'iCal à une vraie connexion raccourcit radicalement cette fenêtre, de plusieurs minutes à quelques secondes. C'est une amélioration réelle et elle élimine la plupart des incidents. Mais elle n'élimine pas la catégorie du problème, car une conception basée sur l'envoi signifie encore que plusieurs copies existent et sont réconciliées après coup.
Il existe aussi un échec plus subtil que la vitesse ne peut pas résoudre. Certains canaux appliquent leurs propres ajustements automatiques à la disponibilité — en rajoutant une chambre quand une annulation arrive, par exemple. Si votre système écrit un nombre absolu au moment exact où le canal applique son propre delta, les deux opérations peuvent se produire dans n'importe quel ordre, et le résultat est parfois supérieur à la vérité.
La solution structurelle consiste à arrêter de garder des copies. La disponibilité est calculée à partir d'un seul pool de chambres réelles, et chaque canal est une vue sur ce pool plutôt qu'un propriétaire d'une partie de celui-ci. Quand une réservation arrive de n'importe où, le pool se réduit, et chaque canal est corrigé pour correspondre au nouveau compte.
Ce dernier point compte plus qu'il n'y paraît. Un système qui ne peut pas lire l'état actuel d'un canal a deux options : deviner, ou le dire. Deviner dans le sens de « probablement encore disponible » est exactement comment une chambre se vend deux fois. Refuser de deviner, c'est ce qui fait la différence entre un système généralement juste et un système sur lequel on peut vraiment compter en période de forte occupation.