Scaling beyond one: How Airbnb evolved its data architecture for a multi-product world

Airbnb · 2025 · 4. Điều chỉnh · Độ khó: Dễ — bài gốc

Bối cảnh

• Bản Summer Release (5/2025): Airbnb thiết kế lại app, làm lại Experiences, ra mắt Services. Kho dữ liệu offline (phục vụ phân tích, khoảng 10 năm tuổi, xây quanh Homes) phải đón thêm hai trụ sản phẩm mới.
• Bài chỉ nói về data warehouse offline, không nói hệ thống online phục vụ app.
• Rủi ro nếu không có chiến lược: data silo, số liệu không nhất quán, nợ kỹ thuật.

Thay đổi chính

• Bài toán lõi: tách riêng hay gộp chung (monolithic)? Tách riêng thì mỗi sản phẩm một bộ bảng, sạch và vừa vặn, nhưng logic bị nhân bản. Gộp chung thì tái sử dụng tối đa và nhất quán, nhưng dễ cồng kềnh. Theo Airbnb: không cách nào tốt hơn ở mọi domain.
• Ba nguyên tắc bắt buộc (tập trung):
  1. Không mô hình lai: một domain hoặc tách hẳn, hoặc gộp hẳn;
  2. Đặt tên ID nhất quán: tách thì dùng ID riêng cho từng sản phẩm (id_experience); gộp thì dùng ID chung + cột loại sản phẩm (id_product_listing + dim_product_type);
  3. Namespace rõ: namespace theo sản phẩm, namespace global, namespace của team.
• Hướng dẫn chọn (phi tập trung, mỗi team tự quyết): thuộc tính chung hay riêng; có scale khi thêm sản phẩm thứ 4, thứ 5 không; DB online phía trên tổ chức ra sao; người dùng phía dưới query thế nào; khả năng bảo trì; khối lượng dữ liệu; tương thích (không làm hỏng Homes); số liệu kinh doanh vẫn đúng. Câu hỏi quyết định nhất: thuộc tính phần lớn chung hay phần lớn riêng?
• Kết quả áp dụng:
  • Tách riêng cho domain gần trải nghiệm user: listing (khái niệm mới "offering" cha–con), availability (giờ làm việc thay cho ngày), location (vùng phục vụ theo bán kính), hành vi guest (khối lượng lớn).
  • Gộp chung cho khái niệm xuyên sản phẩm: messaging (một thread có thể trải nhiều sản phẩm), payments (vốn đã không phụ thuộc sản phẩm), customer support.

Thách thức

• Dữ liệu online và event log được tối ưu cho tốc độ và ổn định của app, không cho phân tích, nên warehouse phải là tầng dịch (translation layer).
• Nợ dữ liệu: bảng và dashboard cũ (Experiences cũ) có hàng trăm người dùng phía dưới, nên phải chạy pipeline song song để kiểm chứng và loại bỏ thật chậm. Vài tháng sau vẫn đang làm.

Vì sao

Theo Airbnb: cân bằng giữa nhất quán (nguyên tắc tập trung) và linh hoạt theo domain (hướng dẫn phi tập trung).

Bài học cho SWE

• Câu hỏi "tách hay gộp" xuất hiện ở cả tầng dữ liệu, không chỉ ở service. Câu trả lời tuỳ domain: khái niệm xuyên suốt (thanh toán, tin nhắn) thì gộp, khái niệm đặc thù thì tách. Cùng tinh thần với Monolith và microservices — đi và quay lại.
• Cấm mô hình lai để tránh trạng thái "nửa nọ nửa kia" khó hiểu về sau.
• Mô hình dữ liệu tối ưu cho online khác mô hình tối ưu cho phân tích. Cùng ý với OLTP/OLAP của Grab (Grab 2022).
• Đây là bài về data warehouse, ít liên quan tới scale hệ thống online.

Liên quan

• Chọn database theo workload
• Monolith và microservices — đi và quay lại