2つのチャネルの間にあるギャップは、速さでは埋まりません。埋めるのは、それぞれが自分のコピーを信じる複数のコピーではなく、すべてのチャネルが同じ1つの在庫プールを参照する仕組みです。
ダブルブッキングのほとんどは、システムが遅いせいで起きるわけではありません。同じ部屋が複数の場所に同時に記録され、それぞれの場所が自分のコピーだけを信じていることが原因です。真実が複数のバージョンで存在する限り、2つのバージョンが食い違う瞬間は必ず訪れます——速度はその瞬間を短くするだけで、なくすことはできません。
土曜の夜、最後の1室が2つのチャネルに掲載されている場面を想像してください。2人のゲストが数秒差で予約します。それぞれのチャネルは自分の在庫コピーを確認し、空室と判断して受け付けます。クローズの指示が2番目のチャネルに届くころには、2件目の予約はすでに成立しています。
誰も間違いを犯したわけではありません。両方のチャネルは設計どおりに動作しました。問題は構造にあります。2つのシステムが同じ部屋を自分のものだと同時に信じることを許されていたのです。
iCalでカレンダーを連携するのは、多くの人にとって最初の一歩であり、それ自体は理にかなっています。しかしiCalはプル型のフォーマットです。相手側が自分のスケジュールでカレンダーファイルを取得しに来るのであり、その間隔は通常数十分、プラットフォームが混雑しているときはさらに長くなります。即時性はなく、保証もありません。
iCalから本当のリアルタイム接続に切り替えると、このギャップは数分から数秒へと大幅に短縮されます。これは本物の改善であり、ほとんどの事故を防ぎます。しかし、根本の原因はなくなりません。プッシュ型の設計である以上、複数のコピーが存在し、事後にそれを調整しているだけだからです。
速さでは対処できない、もっと見えにくい失敗もあります。一部のチャネルは在庫に対して自動調整を行います——例えばキャンセルが入ったときに部屋を自動的に戻すような処理です。あなたのシステムが、チャネルが自分の増減を適用しているまさにその瞬間に絶対値を書き込むと、2つの操作の順序が入れ替わり、結果が実際より多く表示されることがあります。
構造的な解決策は、コピーを持つことをやめることです。在庫は実際の部屋という単一のプールから計算され、各チャネルはその一部を所有するのではなく、そのプールを見るビューにすぎません。予約がどこから来ても、そのプールは減り、すべてのチャネルは新しい数に合わせて修正されます。
最後の点は見た目以上に重要です。チャネルの現在の状態を読み取れないシステムには2つの選択肢しかありません。推測するか、推測できないと認めるかです。「おそらくまだ空いている」という方向に推測することが、まさに部屋が二重に売れる原因になります。推測を拒むことこそが、「たいてい正しい」システムと「満室のときに本当に頼れる」システムの違いです。