Vì sao lịch iCal giữa Airbnb và Booking.com trễ hàng giờ: bài toán pull và push

Một khách đặt villa trên Booking.com lúc 10:05. Email xác nhận về ngay, chủ nhà yên tâm vì nghĩ Airbnb đã tự khóa những đêm đó. Thật ra chưa. Cho tới lần tiếp theo Airbnb đọc lịch của Booking.com, những đêm đó vẫn mở cho bất kỳ ai tìm trên Airbnb.

Nhìn từ góc kỹ thuật, đây là bài toán pull và push quen thuộc, nhưng hậu quả rất đời thường: hai khách cùng đặt một phòng. Bài này giải thích vì sao đồng bộ lịch bằng iCal luôn trễ, cách tính "cửa sổ rủi ro", và vì sao kết nối trực tiếp qua API mới thật sự thu hẹp được nó.

Lịch đồng bộ của từng nền tảng trong bài lấy từ trang trợ giúp chính thức của Airbnb, Booking.com và Agoda, kiểm tra ngày 16/10/2026.

1. iCal thực chất là gì

iCal ở đây là một file .ics theo chuẩn iCalendar (RFC 5545), được đặt ở một URL công khai. Mỗi đặt phòng hoặc mỗi khoảng ngày bị khóa là một VEVENT có ngày bắt đầu và ngày kết thúc:

BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
DTSTART;VALUE=DATE:20270206
DTEND;VALUE=DATE:20270209
SUMMARY:Reserved
END:VEVENT
END:VCALENDAR

Mỗi nền tảng xuất một link như vậy cho lịch của bạn, và nhập link của các nền tảng khác. Điểm mấu chốt: file .ics chỉ là một file nằm chờ được đọc. Nó không chủ động báo cho ai biết khi có thay đổi. Đây là mô hình pull (polling) thuần túy.

2. Bên nhập quyết định lịch đồng bộ

Vì là pull, tốc độ không do bên xuất quyết định, mà do bên nhập. Lịch Booking.com của bạn có thể cập nhật tức thì, nhưng Airbnb chỉ biết có đặt phòng mới khi Airbnb tự đi lấy file.

Vài chi tiết trong tài liệu của các nền tảng:

• Booking.com nói rõ việc đồng bộ không diễn ra ngay khi có đặt phòng, và nêu đặt trùng là hậu quả có thể xảy ra.
• Airbnb nói nếu kết nối nhiều lịch, chúng có thể cập nhật vào những thời điểm khác nhau. Airbnb cũng giới hạn số lần yêu cầu cập nhật thủ công: vượt giới hạn thì phải chờ lần tự động tiếp theo.
• Agoda không công bố chu kỳ. Nếu một loại phòng chuyển từ một phòng lên nhiều phòng, kết nối lịch có thể bị tắt tự động.

3. Vì sao nút "Sync now" không sửa được bên kia

Đây là hiểu lầm phổ biến nhất. Có đặt phòng mới trên Airbnb, chủ nhà mở lịch Airbnb và bấm Refresh, rồi chờ Booking.com cập nhật. Không có gì xảy ra.

Lý do: trong mô hình pull, mỗi nút chỉ kéo dữ liệu về chính trang đang mở. Refresh của Airbnb kéo các lịch khác vào Airbnb. Import now của Booking.com kéo các lịch khác vào Booking.com. Không có nút nào đẩy đặt phòng mới ra ngoài.

Thêm một cái bẫy: đừng dựa vào chuỗi đồng bộ A → B → C. Các nền tảng không cam kết sẽ xuất lại những ngày mà họ nhập từ nơi khác. Airbnb còn nói ngày bị khóa trên lịch khác "có thể có hoặc không" hiện ra. Muốn chắc chắn, mỗi trang phải nhập trực tiếp link của từng trang còn lại.

4. Tính cửa sổ rủi ro

Cửa sổ rủi ro là khoảng thời gian một đêm đã bán trên trang A nhưng vẫn còn mở trên trang B.

Ví dụ: Airbnb pull lịch Booking.com lần gần nhất lúc 09:00, nên lần tiếp theo khoảng 12:00. Khách đặt trên Booking.com lúc 10:05. Từ 10:05 đến 12:00, gần hai giờ, Airbnb vẫn bán những đêm đó.

Ba hệ quả:

• Trường hợp xấu nhất bằng đúng chu kỳ của bên nhập: tối đa 3 giờ trên Airbnb, 2 giờ trên Booking.com, không rõ trên Agoda.
• Trung bình, cửa sổ dài khoảng một nửa chu kỳ, vì đặt phòng rơi vào một thời điểm ngẫu nhiên giữa hai lần pull. Một nửa của 3 giờ vẫn là 90 phút.
• Mỗi kênh thêm vào mở thêm một cửa sổ, chạy theo đồng hồ riêng của nó.

Cửa sổ chỉ gây hại khi có người khác đặt cùng những đêm đó ngay trong lúc nó còn mở. Vì vậy cùng một cấu hình có thể chạy êm vào tháng 5, nhưng hỏng vào cuối tháng 12 hay dịp lễ dài, khi lượt tìm phòng phút chót cho cùng ngày dồn lên.

5. Không đổi được chu kỳ thì thu hẹp cửa sổ

Lịch pull của nền tảng là thứ bạn không kiểm soát được. Những gì làm được nằm ở phía bạn:

1. Pull thủ công ở các trang còn lại sau mỗi đặt phòng. Gắn việc này với email xác nhận: Import now trên Booking.com, Refresh trên Airbnb, Refresh connections trên Agoda. Cửa sổ vài giờ rút xuống còn bằng thời gian bạn đọc email.
2. Khóa tay những ngày cao điểm ngay lập tức, đừng chờ iCal.
3. Dọn feed trùng và feed chết. Một feed nhập hai lần, một link từ công cụ cũ, một kết nối đang báo lỗi. Feed ngừng cập nhật còn nguy hiểm hơn feed chậm.
4. Tự đo độ trễ một lần: khóa một ngày vắng trên trang A, ghi lại giờ, xem khi nào nó hiện trên trang B, rồi mở lại.
5. Trong tuần cao điểm, chỉ để một kênh bán các ngày sát nút. Càng ít kênh bán cùng một đêm, càng ít khả năng "đua" nhau.

Một lưu ý: để trống một đêm giữa hai lượt khách giúp bảo vệ việc dọn phòng, nhưng không ngăn hai khách cùng đặt một đêm trong cửa sổ iCal.

6. Push qua API: cửa sổ ngắn hơn, nhưng không bằng 0

Kết nối trực tiếp qua API đảo ngược mô hình: thay vì chờ bên kia đến lấy, hệ thống của bạn đẩy thay đổi tới từng kênh qua kết nối riêng của kênh đó. Một vài nguyên tắc thiết kế đáng chú ý khi làm kiểu kết nối này:

• Một lịch cho mỗi phòng là nguồn sự thật duy nhất. Mọi kênh được cấp dữ liệu từ đó. Đặt phòng từ kênh nào cũng về cùng một lịch và làm giảm số phòng trống trên mọi kênh còn lại.
• Đẩy nhiều hơn ngày trống: giá đêm, số đêm tối thiểu và tối đa, đóng nhận khách, đóng trả phòng, ngừng bán.
• Cập nhật đi qua hàng đợi có retry. Nếu kênh từ chối một cập nhật, nó phải được ghi lại, không được rơi mất trong im lặng.
• Số phòng chặn trên số phòng trống: một phòng duy nhất không bao giờ được bán thành hai.

Nhưng push không xóa hẳn đặt trùng. Vẫn còn những nguyên nhân sau: kênh từ chối hoặc xử lý chậm cập nhật ở phía họ, hai khách đặt trong cùng một khoảng xử lý ngắn, số phòng khai báo sai, và một feed iCal cũ vẫn chạy trên OTA sau khi đã chuyển sang API. Cái cuối cùng rất hay bị quên: khi chuyển sang API, hãy xóa các link iCal cũ.

7. Khi nào iCal là đủ, khi nào cần API

iCal vẫn ổn cho một hai chỗ ở mỗi loại một phòng, bán trên hai kênh, vào mùa vắng. Nên chuyển sang kết nối trực tiếp khi:

• Bạn bán nhiều phòng giống nhau trong cùng một loại phòng. Booking.com và Agoda chỉ cho đồng bộ lịch khi mỗi loại có một phòng, nên iCal thậm chí không dùng được.
• Bạn bán trên từ ba kênh trở lên, nên mỗi đặt phòng mở ra hai cửa sổ trở lên.
• Mùa cao điểm có nhiều đặt phòng trong tuần và bạn không thể canh từng email.
• Đã từng mất một ngày xin lỗi và đổi phòng vì đặt trùng.

Tóm lại theo ngôn ngữ của dân kỹ thuật: iCal là polling với chu kỳ do người khác đặt. Mọi giải pháp "làm iCal nhanh hơn" thực ra chỉ là pull thủ công thường xuyên hơn. Muốn rút ngắn thật sự, phải chuyển sang push.

Bài gốc (tiếng Anh), kèm link tới từng trang trợ giúp của Airbnb, Booking.com và Agoda: https://www.santara.ai/blog/ical-sync-delay/