La brecha entre dos canales no se cierra con velocidad. Se cierra teniendo un único grupo de disponibilidad del que lee cada canal, en vez de varias copias que se creen a sí mismas.
Casi ninguna doble reserva la causa un sistema lento. La causa que la misma habitación se registre en varios lugares a la vez, y cada lugar confía en su propia copia. Mientras la verdad exista en más de una versión, siempre habrá un momento en que dos versiones no coincidan — y la velocidad solo acorta ese momento, nunca lo elimina.
Imagina la última habitación de un sábado por la noche, publicada en dos canales. Dos huéspedes reservan con segundos de diferencia. Cada canal consulta su propia copia de la disponibilidad, ve la habitación libre y acepta. Para cuando la orden de cierre llega al segundo canal, la segunda reserva ya existe.
Nadie cometió un error. Ambos canales se comportaron exactamente como fueron diseñados. El fallo es arquitectónico: a dos sistemas se les permitió creer que eran dueños de la misma habitación.
Enlazar calendarios con iCal es el primer paso más habitual, y es razonable. Pero iCal es un formato de extracción: el otro lado descarga tu archivo de calendario según su propio horario, normalmente cada diez o veinte minutos, y a veces más si la plataforma está muy ocupada. Nada de esto es instantáneo, y nada está garantizado.
Pasar de iCal a una conexión real reduce drásticamente la ventana, de minutos a segundos. Es una mejora real y elimina la mayoría de los incidentes. Pero no elimina la categoría del problema, porque un diseño basado en envíos todavía significa que existen varias copias que se reconcilian después de los hechos.
También hay un fallo más sutil que la velocidad no puede tocar. Algunos canales aplican sus propios ajustes automáticos a la disponibilidad — por ejemplo, devolver una habitación cuando llega una cancelación. Si tu sistema escribe un número absoluto en el mismo instante en que el canal aplica su propio cambio, las dos operaciones pueden llegar en cualquier orden, y el resultado a veces queda por encima de la verdad.
La solución estructural es dejar de mantener copias. La disponibilidad se calcula a partir de un único conjunto de habitaciones reales, y cada canal es una vista sobre ese conjunto, no el dueño de una parte de él. Cuando llega una reserva desde cualquier lugar, el conjunto se reduce, y cada canal se corrige para coincidir con el nuevo número.
Ese último punto importa más de lo que parece. Un sistema que no puede leer el estado actual de un canal tiene dos opciones: adivinar o decirlo. Adivinar en la dirección de «probablemente sigue disponible» es exactamente cómo una habitación se vende dos veces. Negarse a adivinar es lo que marca la diferencia entre un sistema que suele tener razón y uno en el que realmente puedes confiar con el hotel lleno.