How Airbnb rebuilt its data architecture for a multi-product world

With its May 2025 Summer Release, Airbnb relaunched Experiences and introduced Services, forcing its data teams to evolve a decade-old offline data warehouse to support three distinct product lines. Engineers faced the classic trade-off between separate data models, which keep each product's data clean but duplicate logic, and monolithic models, which maximize reuse but risk becoming unwieldy. Recognizing no single approach fit every domain, they designed a framework blending firm centralized principles with decentralized, domain-specific modeling choices.

The framework rests on three core principles: no hybrid models (a domain must be either fully separate or fully monolithic), consistent identifier conventions (product-specific IDs for separate models, generic IDs plus a type column for monolithic ones), and clear namespace organization separating product-specific, cross-cutting, and team-owned tables. On top of these, teams received practical guidelines covering shared versus unique attributes, future scalability, upstream/downstream alignment, maintainability, and business continuity to help them choose the right path.

In practice, the decisive factor was whether product lines shared common attributes or diverged significantly. Teams closest to user-facing features chose separate models, especially to handle entirely new Services concepts like 'service offerings' (multiple variants nested under one listing) and 'business hours' (flexible time-range bookings instead of fixed slots). The case illustrates how large-scale data engineering organizations can preserve consistency and avoid technical debt while rapidly expanding into new product domains.