הפער בין שני ערוצים לא נסגר במהירות. הוא נסגר בכך שיש מאגר זמינות אחד שכל הערוצים קוראים ממנו, במקום כמה עותקים שכל אחד מהם מאמין שהוא הנכון.
כמעט אף הזמנה כפולה לא נגרמת ממערכת איטית. היא נגרמת מכך שאותו חדר נרשם במקומות שונים בו-זמנית, וכל מקום סומך על העותק שלו. כל עוד האמת קיימת ביותר מגרסה אחת, יש תמיד רגע שבו שתי הגרסאות לא מסתדרות — והמהירות רק מקצרת את הרגע הזה, לעולם לא מבטלת אותו.
תארו לעצמכם את החדר האחרון לליל שבת, רשום בשני ערוצים. שני אורחים מזמינים בהפרש של כמה שניות. כל ערוץ בודק את העותק שלו של הזמינות, רואה שהחדר פנוי, ומאשר. עד שפקודת הסגירה מגיעה לערוץ השני, ההזמנה השנייה כבר קיימת.
אף אחד לא טעה. שני הערוצים התנהגו בדיוק כמו שתוכננו. הכשל הוא ארכיטקטוני: שתי מערכות קיבלו רשות להאמין שהן שולטות באותו חדר.
חיבור לוחות שנה באמצעות iCal הוא הצעד הראשון הנפוץ ביותר, וזו בחירה הגיונית. אבל iCal הוא פורמט מבוסס-שליפה: הצד השני שולף את קובץ הלוח שלכם בלוח זמנים שלו, שנמדד בדרך כלל בעשרות דקות, ולפעמים יותר כשהפלטפורמה עמוסה. שום דבר בו אינו מיידי, ושום דבר בו אינו מובטח.
המעבר מ-iCal לחיבור אמיתי מקצר את החלון הזה בצורה דרמטית, מדקות לשניות. זה שיפור אמיתי שמסלק את רוב התקריות. אבל הוא לא מסלק את הקטגוריה כולה, כי עיצוב מבוסס-דחיפה עדיין אומר שקיימים כמה עותקים שמתואמים רק בדיעבד.
קיים גם כשל עדין יותר שהמהירות לא נוגעת בו. ערוצים מסוימים מחילים התאמות אוטומטיות משלהם על הזמינות — למשל, מחזירים חדר כשמגיע ביטול. אם המערכת שלכם כותבת מספר מוחלט בדיוק באותו רגע שבו הערוץ מחיל את השינוי שלו, שתי הפעולות יכולות לקרות בכל סדר, והתוצאה לפעמים גבוהה מהמציאות.
התיקון המבני הוא להפסיק לשמור עותקים. הזמינות מחושבת ממאגר אחד של חדרים אמיתיים, וכל ערוץ הוא רק חלון תצוגה לאותו מאגר, ולא בעל חלק ממנו. כשמגיעה הזמנה מכל מקום שהוא, המאגר מצטמק, וכל ערוץ מתעדכן בהתאם למספר החדש.
הנקודה האחרונה הזו חשובה יותר ממה שנראה. למערכת שלא יכולה לקרוא את המצב הנוכחי של ערוץ יש שתי אפשרויות בלבד: לנחש, או להגיד שאינה יודעת. ניחוש בכיוון של “כנראה עדיין פנוי” הוא בדיוק הדרך שבה חדר נמכר פעמיים. הסירוב לנחש הוא מה שמייצר את ההבדל בין מערכת שבדרך כלל נכונה למערכת שאפשר לסמוך עליה באמת בימים של תפוסה מלאה.