Глава 38. Airbnb — System Design Space

Проектирование Airbnb — классическая задача на System Design интервью, которая объединяет геопоиск, управление доступностью, динамическое ценообразование и систему доверия. Это двусторонний маркетплейс с уникальными техническими вызовами.

Источник

Acing the System Design Interview

Детальный разбор проектирования Airbnb есть в книге Zhiyong Tan.

Читать обзор

Ключевые особенности Airbnb

7M+ listings

220+ стран

150M+ гостей

2B+ ночей забронировано

1Функциональные требования

Guest Flow

•Поиск по локации, датам, количеству гостей
•Фильтрация (цена, тип жилья, amenities)
•Просмотр листинга с фото и отзывами
•Бронирование и оплата
•Мессенджер с хостом

Host Flow

•Создание и редактирование листинга
•Управление календарём доступности
•Настройка pricing rules
•Подтверждение/отклонение бронирований
•Получение выплат

2Нефункциональные требования

Low Latency Search

Геопоиск < 200ms. Пользователи ожидают мгновенные результаты при изменении карты.

High Availability

99.99% uptime. Бронирования — это деньги, простой недопустим.

Consistency

Нельзя продать одну ночь дважды. Strong consistency для бронирований.

Масштаб системы

Листингов:7M

Поисков/день:100M

Бронирований/день:1M

Фото:500M+

3Geo Search: Поиск по локации

Связанная тема

Proximity Service

Alex Xu подробно разбирает геопоиск в главе о Proximity Service.

Читать обзор

Подходы к геоиндексированию

Подход	Описание	Use Case
Geohash	Строковое представление координат, prefix matching	Redis, простые запросы
Quadtree ✓	Рекурсивное деление пространства на 4 части	In-memory поиск, Uber
S2 Geometry	Google's библиотека, hierarchical cells	Google Maps, Foursquare
PostGIS	PostgreSQL extension с R-tree индексами	Небольшой масштаб

Архитектура поиска Airbnb

1Elasticsearch как основной поисковый движок с geo_point типом
2geo_bounding_box query для видимой области карты
3Availability filter — join с календарём доступности
4Ranking — ML модель для персонализации результатов

Elasticsearch Query Example

{
  "query": {
    "bool": {
      "filter": [
        {
          "geo_bounding_box": {
            "location": {
              "top_left": { "lat": 40.73, "lon": -74.1 },
              "bottom_right": { "lat": 40.01, "lon": -73.12 }
            }
          }
        },
        { "term": { "property_type": "entire_home" } },
        { "range": { "price": { "gte": 50, "lte": 200 } } },
        { "range": { "guests": { "gte": 2 } } }
      ]
    }
  }
}

4Availability Calendar

Связанный кейс

Hotel Booking

Похожая проблема управления доступностью разобрана в кейсе Hotel Booking.

Читать обзор

⚠️ Главная сложность

Календарь должен быть eventually consistent для чтения (поиск), но strongly consistent для записи (бронирование). Нельзя продать одну ночь дважды!

Схема данных

-- Календарь по дням
CREATE TABLE availability (
  listing_id   UUID,
  date         DATE,
  status       ENUM('available', 
               'blocked', 'booked'),
  price        DECIMAL,
  min_nights   INT,
  PRIMARY KEY (listing_id, date)
);

-- Индекс для поиска
CREATE INDEX idx_available 
ON availability(date, status) 
WHERE status = 'available';

Оптимизации

•Date ranges: Хранить интервалы вместо отдельных дней
•Bitmap: 365 бит на год, быстрые операции
•Caching: Redis для hot listings
•Sharding: По listing_id для изоляции

Синхронизация с поиском

Elasticsearch не должен содержать календарь — он слишком часто меняется. Вместо этого используется двухэтапный подход:

1ES возвращает кандидатов по geo + filters
2Availability Service фильтрует по календарю (batch lookup)
3Ranking Service сортирует финальные результаты

5Booking Flow: Бронирование

Instant Book vs Request to Book

Instant Book

Гость бронирует сразу, хост не подтверждает.

+ Лучший UX для гостей
+ Выше конверсия
- Риск для хостов

Request to Book

Хост должен подтвердить бронирование.

+ Контроль для хостов
- Задержка для гостей
- Ниже конверсия

Процесс бронирования (Instant Book)

1Check availability: Атомарная проверка + блокировка дат (Redis SETNX или SELECT FOR UPDATE)
2Calculate price: Base price + cleaning fee + service fee + taxes
3Payment authorization: Stripe PaymentIntent (hold, не charge)
4Create reservation: Транзакция: booking + update availability
5Notifications: Email/push гостю и хосту
6Payment capture: Charge после check-in (или 24h до)

Распределённые транзакции

Бронирование затрагивает несколько сервисов. Используется Saga pattern:

Saga: CreateBooking
├── Step 1: Reserve dates (Availability Service)
│   └── Compensate: Release dates
├── Step 2: Authorize payment (Payment Service)
│   └── Compensate: Cancel authorization
├── Step 3: Create booking (Booking Service)
│   └── Compensate: Delete booking
└── Step 4: Send notifications (Async, no compensate)

6Dynamic Pricing Engine

Компоненты цены

Host устанавливает:

Base nightly rate
Weekend pricing
Weekly/monthly discounts
Cleaning fee
Extra guest fee

Airbnb добавляет:

Service fee (guest): ~14%
Service fee (host): ~3%
Occupancy taxes
Currency conversion

Smart Pricing (ML)

Airbnb предлагает хостам автоматическое ценообразование на основе:

Demand signals:

Сезонность
События в городе
День недели

Supply signals:

Occupancy rate
Lead time
Конкуренты

Listing signals:

Рейтинг
Amenities
Фото качество

7Trust & Safety System

Двустороннее доверие

Для гостей:

Verified photos
Reviews от других гостей
Superhost badge
Airbnb Cover (страховка)
24/7 support

Для хостов:

ID verification
Guest reviews
Damage protection
Security deposit
Background checks

Fraud Detection

•ML модели: Детекция фейковых листингов, подозрительных бронирований
•Risk scoring: Каждый пользователь и транзакция получают risk score
•Message scanning: NLP для детекции off-platform payments
•Photo verification: CV для проверки соответствия фото реальности

Review System

Двусторонние отзывы — ключ к доверию. Особенности:

•Blind reviews: Оба видят отзывы только после того, как оба написали
•14-day window: Ограниченное время на написание отзыва
•Response: Хост может ответить на отзыв публично

8High-Level архитектура и стандартные сценарии

Architecture + Scenario Explorer

Discovery and booking paths for two-sided marketplace

Discovery Plane (read heavy)

Guest App

search + filters

API Gateway

auth + routing

Search Service

geo index query

Availability Read

calendar projection

Ranking Service

relevance + ML

Transaction Plane (consistency first)

Host Console

approve / update

API Gateway

shared ingress

Booking Orchestrator

saga workflow

Payment Service

auth / refund

Reservation Store

booking state

Inventory Lock

date lock/release

Notification

email / push / sms

Host Console

approve / update

API Gateway

shared ingress

Booking Orchestrator

saga workflow

Payment Service

auth / refund

Reservation Store

booking state

Inventory Lock

date lock/release

Notification

email / push / sms

Маркетплейс разделяет discovery path и transactional path: быстрый геопоиск отдельно от консистентного booking-контура.

Выбери сценарий сверху, чтобы увидеть конкретный путь обработки запроса через архитектуру.

Важно разделять поисковый read-path и booking write-path: discovery может быть eventual, а операции бронирования должны идти через строгий transactional контур с lock + payment orchestration.

9Ключевые моменты для интервью

✓ Обязательно обсудить

•Geo search: выбор индекса (Geohash vs Quadtree vs S2)
•Availability: как синхронизировать с поиском
•Double booking prevention: locking strategy
•Two-sided marketplace: разные UX для guest/host
•Payment flow: authorization vs capture

💡 Дополнительные темы

•Smart Pricing ML model
•Search ranking personalization
•Photo storage и CDN
•Internationalization (currencies, languages)
•Experiences (не только жильё)

Типичные ошибки на интервью

✗Забыть про двустороннюю природу маркетплейса (guest + host flows)
✗Хранить availability в search index (слишком часто меняется)
✗Игнорировать timezone проблемы для календаря
✗Не обсудить trust & safety для маркетплейса