Scaling Beyond One: How Airbnb Evolved Its Data Architecture for a Multi-Product World
Author: Patrick Lam, Namrata Lamba, Jamie Stober (Airbnb) | Source: Medium (Airbnb Engineering) | Published: 2026-06-10
한 줄 요약
Airbnb가 Homes 단일 제품에서 Homes·Experiences·Services 3제품으로 확장하며, “separate vs monolithic 데이터 모델” 딜레마를 중앙 원칙 + 분권 가이드라인으로 풀어 도메인별 최적 선택을 가능하게 한 데이터 모델링 프레임워크.
핵심 주장/내용
- 핵심 딜레마: ① separate 모델(제품별 별도 테이블, 깔끔·맞춤형이나 로직 중복) vs ② monolithic 모델(통합 테이블, 재사용성·일관성이나 unwieldy). 어느 쪽도 보편 우월 아님 — 도메인에 따라 다름
- 3대 중앙 원칙: ① no hybrid(완전 separate 또는 완전 monolithic) ② 일관된 식별자 명명(separate는 제품별 ID
id_experience, monolithic은 genericid_product_listing+dim_product_type) ③ 명확한 namespace(제품별/global/team별) - 분권 가이드라인: shared vs unique 속성, 미래 진화, upstream 정렬, downstream 소비자, 코드 유지보수성, 데이터 볼륨, 호환성, 비즈니스 연속성 → 팀이 도메인별로 판단
- 결정적 요인: 제품 라인이 공통 속성을 공유하나 vs 고유 속성이 많나
- separate(제품 고유 로직): Listings(Service offering의 many-to-one), Availability(business hours), Location(Service area radius), Guests(고볼륨 funnel)
- monolithic(cross-cutting): Messaging(제품 넘나드는 thread), Payments(product-agnostic), Customer support
- 오프라인 웨어하우스 = translation layer: 온라인 production은 transactional 속도 최적화 → 오프라인이 표준화·신뢰 source로 변환
주요 수치 / 사실
- 2025년 5월 Summer Release로 Experiences 재출시 + Services 신규 출시
- 10년 된 인프라를 2개 신제품 pillar에 통합
- 데이터 debt 관리: 레거시 테이블은 수백 다운스트림 소비자 → dual pipeline 검증 + 느린 deprecation
- 교훈: “best answer는 one-size-fits-all이 거의 아니다 — 중앙 일관성 + 도메인 유연성의 균형”
관련 위키
Source: 원문 보기