AIRBNB 2026-06-09

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

Summary¶

With Airbnb's May 2025 Summer Release expanding from a single product (Homes) to three (Homes, Experiences, Services), the data engineering team faced a critical question: how to evolve a decade-old offline data warehouse to support new product lines without fragmenting analytics or creating debt. They designed a framework combining three firm foundational principles (no hybrid models, consistent identifier naming, clear namespace organization) with decentralized modeling guidelines that empowered each domain team to choose between separate or monolithic data models based on their specific domain characteristics. Product-facing teams (listings, availability, location, guests) chose separate models; cross-cutting teams (messaging, payments, customer support) chose monolithic models.

Key takeaways¶

The core trade-off is separate vs. monolithic data models — separate models keep product-specific data clean and tailored but incur duplicated logic; monolithic models maximize reuse and consistency but risk unwieldiness. Neither is universally superior; the optimal choice depends on the domain.
Three foundational principles enforce consistency regardless of modeling choice: (a) no hybrid models — each domain must be fully separate or fully monolithic; (b) consistent identifier naming tied to the model choice (product-specific IDs like id_experience for separate, generic IDs like id_product_listing + dim_product_type column for monolithic); (c) clear namespace organization (product namespaces for product-specific tables, global namespace for cross-cutting, team-specific namespaces for intermediate tables).
The decisive question for teams was attribute commonality — domains where products share mostly common attributes (payments, messaging, support) went monolithic; domains with significant unique attributes (listings, availability, location, guests) went separate.
New product concepts forced separate models — Services introduced fundamentally new data structures: offerings (many-to-one under a parent listing), business hours (flexible time windows → discrete bookable slots), and service areas (radius-based geographic flexibility). These had no parallel in Homes or Experiences.
The offline data warehouse acts as a translation layer — upstream OLTP systems are optimized for transactional speed, not analytics clarity. The data warehouse must transform raw production data into a standardized source of truth for downstream consumers.
Data debt is a first-class concern — legacy tables from old Experiences often have hundreds of downstream consumers, requiring dual pipeline runs for validation and painstakingly slow deprecation cycles. Migration is ongoing months after launch.
Backward and forward compatibility are explicit design guidelines — teams must ensure new Experiences/Services data doesn't break Homes-powering models, handle low-volume new data gracefully, and plan for 4th/5th product lines.
Centralized principles + decentralized execution — the framework balances organizational consistency (principles everyone follows) with domain-specific flexibility (each team decides their model shape), a pattern applicable beyond data modeling.

Systems and concepts extracted¶

Concepts¶

Separate vs. monolithic data models — the fundamental trade-off in multi-product data architecture: per-product tables (tailored but duplicated logic) vs. unified tables (consistent but potentially unwieldy)
Offline data warehouse as translation layer — the warehouse transforms raw OLTP data into a standardized analytical source of truth, absorbing upstream schema messiness
Data debt migration — legacy tables/dashboards that no longer meet new standards must be carefully migrated with dual pipeline runs and slow deprecation
Namespace organization — product namespaces, global namespaces, and team-specific namespaces to give every table clear placement
Consistent identifier naming — structural conventions where ID shape depends on modeling choice (product-specific vs. generic + type column)
Backward compatibility in data models — explicit requirement that new product data must not break existing models powering the core product line

Patterns¶

Domain-driven data modeling choice — empower each team to pick the right model shape for their domain using a shared set of considerations
No hybrid data models — enforce that a domain is fully separate or fully monolithic to prevent future confusion
Product-specific vs. generic identifiers — naming conventions tied to modeling approach (id_experience vs. id_product_listing + dim_product_type)
Dual-pipeline deprecation — run old and new pipelines simultaneously for validation before decommissioning legacy tables
Foundational principles with decentralized guidelines — central guardrails + domain-team autonomy as an organizational scaling pattern

Caveats¶

The post focuses exclusively on the offline data warehouse (analytics-oriented) — not the online data systems serving the app. The authors explicitly note these domains have fundamentally different requirements and design philosophies.
No operational numbers (latency, throughput, table counts, pipeline runtimes) are provided.
The approach is still evolving — the authors acknowledge ongoing migration work months after launch.
The article is more about organizational process and framework design than low-level system architecture.