System Design Space
Граф знанийНастройки

Обновлено: 25 марта 2026 г. в 04:52

Airbnb

medium

Классическая задача: geo-search, availability calendar, dynamic pricing, two-sided marketplace.

Airbnb добавляет к бронированию еще один слой сложности: пользовательский контент, host-generated supply, trust mechanisms и геопоиск.

Кейс помогает соединить lifecycle объявления, календарь доступности, ranking, messaging, pricing и booking flow в архитектуру двустороннего marketplace.

В интервью и design review он полезен тем, что показывает, умеете ли вы учитывать не только inventory, но и доверие, качество supply и разнообразие пользовательских сценариев.

Business Correctness

Требуется корректное состояние заказа при конкурирующих запросах и ретраях.

User Experience

Надо защищать critical user flow при скачках трафика и частичных деградациях.

Transactional Boundaries

Явно задавайте, где нужна сильная консистентность, а где допустима eventual.

Evolution Path

Покажите, как архитектура растёт от MVP до multi-region масштаба.

Проектирование 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 matchingRedis, простые запросы
Quadtree ✓Рекурсивное деление пространства на 4 частиIn-memory поиск, Uber
S2 GeometryGoogle's библиотека, hierarchical cellsGoogle Maps, Foursquare
PostGISPostgreSQL extension с R-tree индексамиНебольшой масштаб

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

  1. 1Elasticsearch как основной поисковый движок с geo_point типом
  2. 2geo_bounding_box query для видимой области карты
  3. 3Availability filter — join с календарём доступности
  4. 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 не должен содержать календарь — он слишком часто меняется. Вместо этого используется двухэтапный подход:

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

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

Instant Book vs Request to Book

Instant Book

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

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

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

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

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

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

Архитектура + сценарии

Пути discovery и booking для двустороннего маркетплейса

Discovery-плоскость (нагрузка на чтение)

Guest App
поиск + фильтры
API Gateway
авторизация + маршрутизация
Search Service
запрос к geo-индексу
Availability Read
проекция календаря
Ranking Service
релевантность + ML

Transaction-плоскость (консистентность в приоритете)

Host Console
подтверждение / обновление
API Gateway
авторизация + маршрутизация
Booking Orchestrator
saga workflow
Payment Service
auth / refund
Reservation Store
состояние брони
Inventory Lock
блокировка / release дат
Notification
email / push / sms
Маркетплейс разделяет discovery-путь и transactional-путь: быстрый геопоиск изолирован от консистентного контура бронирования.
Выбери сценарий сверху, чтобы подсветить конкретный путь обработки запроса через архитектуру.

Важно разделять поисковый 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 для маркетплейса

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки