A brecha entre dois canais não se fecha com velocidade. Fecha-se com um único pool de disponibilidade consultado por todos os canais, em vez de várias cópias que confiam cada uma em si mesma.
Quase nenhum overbooking é causado por um sistema lento. É causado pelo mesmo quarto registrado em vários lugares ao mesmo tempo, cada lugar confiando na própria cópia. Enquanto a verdade existir em mais de uma versão, sempre haverá um momento em que duas versões discordam — e a velocidade só encurta esse momento, nunca o elimina.
Imagine o último quarto disponível para um sábado à noite, anunciado em dois canais. Dois hóspedes reservam com segundos de diferença. Cada canal verifica a própria cópia da disponibilidade, vê o quarto livre e aceita. No momento em que a instrução de fechamento chega ao segundo canal, a segunda reserva já existe.
Ninguém cometeu erro. Os dois canais se comportaram exatamente como deveriam. A falha é arquitetural: dois sistemas foram deixados crer, cada um por si, que eram donos do mesmo quarto.
Ligar os calendários por iCal é o primeiro passo mais comum, e é razoável. Mas o iCal é um formato baseado em busca periódica: o outro lado busca seu arquivo de calendário conforme a própria agenda, geralmente da ordem de dezenas de minutos, e às vezes mais quando a plataforma está sobrecarregada. Nada nele é instantâneo, e nada nele é garantido.
Trocar o iCal por uma conexão real encurta drasticamente essa janela, de minutos para segundos. Essa é uma melhoria real e elimina a maioria dos incidentes. Mas não elimina a categoria do problema, porque um design baseado em envio ainda significa que várias cópias existem e são reconciliadas depois do fato.
Há também uma falha mais sutil que a velocidade não resolve. Alguns canais aplicam seus próprios ajustes automáticos à disponibilidade — devolvendo um quarto quando chega um cancelamento, por exemplo. Se o seu sistema escreve um número absoluto no exato instante em que o canal aplica o próprio ajuste, as duas operações podem acontecer em qualquer ordem, e o resultado às vezes fica acima da verdade.
A solução estrutural é parar de manter cópias. A disponibilidade é calculada a partir de um único pool de quartos reais, e cada canal é uma visão sobre esse pool, não o dono de uma parte dele. Quando uma reserva chega de qualquer lugar, o pool diminui, e cada canal é corrigido para corresponder à nova contagem.
Esse último ponto importa mais do que parece. Um sistema que não consegue ler o estado atual de um canal tem duas opções: chutar ou avisar. Chutar na direção de “provavelmente ainda disponível” é exatamente como um quarto é vendido duas vezes. Recusar-se a chutar é o que separa um sistema geralmente certo de um sistema em que você realmente pode confiar quando a casa está cheia.