Airbnb усложняет обычное бронирование тем, что здесь нужно одновременно держать в голове геопоиск, календарь доступности, цены, контур бронирования и доверие между двумя сторонами.
Глава собирает в одну архитектуру жизненный цикл объявления, поиск по карте, сообщения, подтверждение брони, правила оплаты и механизмы защиты от злоупотреблений.
В интервью и инженерных обсуждениях этот кейс полезен тем, что быстро показывает, умеете ли вы думать не только об инвентаре, но и о качестве предложения, безопасности и разнообразии пользовательских сценариев.
Геопоиск
Путь поиска по карте должен быстро находить кандидатов, но не тянуть за собой тяжёлую проверку календаря и платежей на каждом запросе.
Календарь доступности
Календарь можно проецировать и кэшировать для поиска, но подтверждение брони обязано проходить через более строгий контур корректности.
Контур бронирования
Бронь затрагивает даты, деньги, состояние заказа и уведомления, поэтому путь подтверждения нужно проектировать как отдельную координируемую операцию.
Доверие и антифрод
Маркетплейс не удерживает пользователей только красивой выдачей: доверие, проверки и борьба с мошенничеством здесь такой же core path, как и бронирование.
Airbnb интересен не только поиском жилья. Это , где геопоиск, календарь доступности, бронирование, цены и механизмы доверия должны работать как единая система. Ошибка в любом из этих контуров быстро превращается либо в потерянную конверсию, либо в реальный операционный инцидент.
Источник
Acing the System Design Interview
В книге Zhiyong Tan есть отдельный разбор Airbnb как системного дизайн-кейса.
Масштаб продукта
1Функциональные требования
Путь гостя
- •Поиск по локации, датам, числу гостей и правилам размещения
- •Фильтрация по цене, типу жилья, удобствам и политике отмены
- •Просмотр карточки объявления с фото, описанием и отзывами
- •Бронирование, оплата и получение подтверждения
- •Обмен сообщениями с хозяином до и после поездки
Путь хозяина
- •Создание и обновление объявления, фото и правил проживания
- •Управление календарём доступности и ограничениями по датам
- •Настройка цен, скидок и правил мгновенного бронирования
- •Подтверждение запросов на бронь и общение с гостем
- •Получение выплат и работа с отзывами после поездки
2Нефункциональные требования
Быстрый поиск
Карта и выдача должны обновляться почти мгновенно, иначе пользователь теряет ощущение живого поиска.
Высокая доступность
Бронирование и поддержка поездки не должны падать в сезонных пиках и во время локальных сбоев.
Корректность бронирования
Один и тот же интервал нельзя подтвердить двум гостям одновременно, даже если поиск и кэш успели устареть.
На верхнем уровне Airbnb разводит быстрый поисковый путь и строгий транзакционный путь. Поисковый контур живёт под жёстким , а контур бронирования обязан сохранять календаря и платежей даже под конкурирующими запросами.
Масштаб системы
3Геопоиск
Связанная тема
Proximity Service
Разбор Alex Xu помогает отдельно понять nearby search, пространственные индексы и геофильтрацию.
Геопоиск в Airbnb не заканчивается на поиске по координатам. После первичного выбора кандидатов система отдельно проверяет календарь и только затем применяет , чтобы учесть релевантность, персональные предпочтения и коммерческие сигналы.
Подходы к геоиндексированию
| Подход | Описание | Когда полезен |
|---|---|---|
| Geohash | Строковое кодирование координат, удобное для prefix-match запросов | Простые lookup-сценарии и Redis |
| Quadtree ✓ | Рекурсивно делит карту на квадранты и хорошо ложится на in-memory поиск | Быстрый отбор кандидатов для выдачи |
| S2 Geometry | Иерархические ячейки сферы, удобные для глобальных карт и сложной геометрии | Глобальные продукты уровня Google Maps |
| PostGIS | Расширение PostgreSQL с пространственными индексами и SQL-операторами | Небольшой масштаб и сильная связка с БД |
Как выглядит поисковый контур Airbnb
- 1Elasticsearch хранит поисковый индекс объявлений с координатами, фильтрами и текстовыми полями.
- 2geo_bounding_box ограничивает поиск текущей видимой областью карты.
- 3Отдельный сервис календаря убирает варианты, которые недоступны на выбранный диапазон дат.
- 4Поверх оставшихся кандидатов запускается персонализированная сортировка результатов.
Пример запроса в Elasticsearch
{
"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 } } }
]
}
}
}4Календарь доступности
Связанный кейс
Hotel Booking
В соседнем кейсе подробно разобрано, как календарная модель ломается под конкурирующими бронированиями.
⚠️ Главная сложность
Календарь доступности можно кэшировать и реплицировать для поиска, но момент подтверждения брони обязан сохранять строгую консистентность. Нельзя подтвердить одну и ту же ночь двум гостям только потому, что поисковая выдача устарела на несколько секунд.
Схема данных
-- Календарь по дням
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';Оптимизации
- •Интервалы дат: хранить диапазоны, если календарь меняется пакетами
- •Bitmap: упаковать занятые дни в битовые маски для быстрых проверок
- •Кэширование: держать горячие календари в Redis рядом с поиском
- •Разделение нагрузки: изолировать горячие объявления от длинного хвоста
По мере роста продукта календарь почти неизбежно приходит к по идентификатору объявления или географическому сегменту. Идея простая: поиск может жить на read-model и кэше, а подтверждение брони должно идти в узкий, хорошо контролируемый источник истины.
Синхронизация с поиском
Полный календарь не стоит держать внутри Elasticsearch: он меняется слишком часто, а индекс станет дорогим и быстро устареет. Поэтому обычно используют двухэтапный сценарий:
- 1Поисковый индекс возвращает кандидатов по карте, фильтрам и базовым признакам.
- 2Сервис календаря пакетно проверяет нужный диапазон дат и выкидывает недоступные варианты.
- 3Финальная выдача доупорядочивается персонализацией и продуктовыми сигналами.
5Контур бронирования
Instant Book и Request to Book
Instant Book
Гость получает подтверждение сразу, без ручного одобрения со стороны хозяина.
- + Самый быстрый путь до оплаты
- + Выше конверсия и меньше трения
- - Больше риска для хозяина
Request to Book
Хозяин сначала просматривает запрос и только потом подтверждает бронь.
- + Больше контроля для хозяина
- - Медленнее путь для гостя
- - Ниже общая конверсия
Процесс мгновенного бронирования
- 1Проверка доступности: атомарно проверить диапазон дат и поставить блокировку через Redis SETNX или SELECT FOR UPDATE.
- 2Расчёт цены: собрать ночные ставки, сборы, налоги и скидки в итоговую сумму.
- 3Авторизация платежа: выполнить Stripe PaymentIntent и удержать сумму без окончательного списания.
- 4Фиксация брони: в одной транзакции сохранить бронь и обновить календарь доступности.
- 5Уведомления: разослать подтверждение гостю и хозяину по email и push-каналам.
- 6Финальное списание: перевести авторизацию в capture по правилам продукта.
Распределённая координация
Бронирование затрагивает календарь, оплату, состояние брони и уведомления, поэтому сценарий удобно собирать через : каждый шаг либо подтверждается, либо откатывается компенсирующим действием.
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)6Динамическое ценообразование
Для Airbnb цена — не статическое поле в карточке, а отдельный контур с собственными сигналами спроса и предложения. В больших городах и в сезонных всплесках именно помогает выровнять загрузку, не ломая понятность продукта для хозяина и гостя.
Из чего складывается цена
Хозяин задаёт
- Базовую цену за ночь
- Надбавки на выходные
- Недельные и месячные скидки
- Плату за уборку и дополнительных гостей
Платформа добавляет
- Сервисный сбор для гостя и хозяина
- Локальные налоги и обязательные сборы
- Конвертацию валют и округление
- Рекомендации для автоматического управления ценой
Smart Pricing
Автоматические рекомендации по цене собирают несколько классов сигналов:
- Сезонность
- События в городе
- День недели и глубина бронирования
- Заполняемость похожих объектов
- Lead time до поездки
- Цены конкурирующих объявлений
- Рейтинг и качество отзывов
- Удобства и тип размещения
- Качество фотографий и контента
7Контур доверия и безопасности
Для Airbnb важен не только checkout-flow. Продукт обязан поддерживать , который проверяет участников, защищает коммуникацию и отдельно занимается , иначе маркетплейс начинает терять обе стороны сразу.
Доверие для обеих сторон
Для гостей
- Проверенные фотографии и описание жилья
- Отзывы других гостей
- Статус Superhost
- Airbnb Cover и поддержка 24/7
- Понятные правила отмены и возврата
Для хозяев
- Проверка личности гостя
- История отзывов и поведения
- Защита от ущерба
- Страховой депозит и правила дома
- Проверки на злоупотребления и серые сценарии
Контур антифрода
- •ML-модели: отсеивают фейковые объявления и подозрительные бронирования.
- •Risk scoring: пользователь, платёж и бронирование получают отдельную оценку риска.
- •Анализ сообщений: NLP помогает замечать попытки увода оплаты за пределы платформы.
- •Проверка фото: CV-модели сопоставляют изображения с заявленным объектом.
Система отзывов
Двусторонние отзывы удерживают баланс между качеством предложения и предсказуемостью опыта для гостя.
- •Blind reviews: стороны видят отзывы только после публикации обеих оценок или завершения окна ожидания.
- •Ограниченное окно: отзыв нужно оставить в течение фиксированного периода после поездки.
- •Публичный ответ: хозяин может прокомментировать отзыв и снять часть неопределённости для будущих гостей.
8Высокоуровневая архитектура и стандартные сценарии
Архитектура и сценарии Airbnb
Поисковый и транзакционный контуры двустороннего маркетплейсаПоисковый контур (нагрузка на чтение)
Транзакционный контур (корректность брони)
Важно отделять поисковый от транзакционного : поисковый контур может жить на индексе и проекциях, а бронь обязана проходить через строгий контур блокировок, платежей и фиксации состояния.
9Что важно проговорить на интервью
✓ Обязательно обсудить
- •Как выбрать геоиндекс и не смешать его с календарём доступности
- •Как синхронизировать поиск, календарь и подтверждение брони
- •Как защититься от двойного бронирования и гонок на популярных объектах
- •Почему у гостя и хозяина разные сценарии, ограничения и ожидаемые сроки ответа
- •Чем отличаются авторизация платежа и окончательное списание
💡 Дополнительные темы
- •Автоматическое управление ценой и его связь с сезонностью и конкурентной средой
- •Персонализация поисковой выдачи и разнообразие результатов
- •Интернационализация: валюты, языки, локальные налоги и правила
- •Расширение продукта с жилья на experiences и другие категории предложения
Если остаётся время, полезно отдельно проговорить путь медиа: исходные фотографии хранятся отдельно, а resized-версии и публичная раздача почти всегда уходят в , чтобы не мешать ни поиску, ни бронированию.
Типичные ошибки на интервью
- ✗Свести кейс только к каталогу и забыть про вторую сторону маркетплейса
- ✗Пытаться держать полный календарь внутри поискового индекса
- ✗Игнорировать таймзоны и локальные правила расчёта ночей
- ✗Не обсуждать доверие, антифрод и качество пользовательского контента
Связанные главы
- Система бронирования отелей - Соседний кейс про календарь доступности, овербукинг и конкуренцию за ограниченный инвентарь.
- Acing the System Design Interview (краткий обзор) - Помогает структурировать ответ на интервью и не потерять продуктовую логику в маркетплейс-кейсе.
- System Design Interview: An Insider's Guide (краткий обзор) - Даёт полезные паттерны для геопоиска, индексации и масштабирования каталога.
- Google Maps / Proximity Service — геопоиск - Показывает, как проектировать nearby search, пространственный индекс и георанжирование.
- Примеры задач по системному дизайну - Ставит Airbnb в общий контекст соседних кейсов и архитектурных компромиссов.
- Uber/Lyft - Полезен для сравнения геодоменов, пути поиска кандидатов и жёстких бюджетов задержки.