Сначала нужно определить, что именно проектируется
Основные сценарии — просмотр отеля и номеров, бронирование с оплатой и отмена. Поиск и подробная административная часть исключены из задачи. Дополнительное условие допускает бронирование на десять процентов сверх номерного фонда. Требуются высокая доступность, работа с одновременными запросами и ответ на бронирование за несколько секунд. Уточнение оплаты позволяет вынести работу с картой к внешнему провайдеру.
Нагрузку оценивают через размер рынка, заполненность и среднюю длительность проживания, затем через воронку просмотров и бронирований. Такой расчёт нужен для понимания порядка величин и соотношения чтения и записи; средняя интенсивность не описывает пики. После этого фиксируются границы системы и API. Важен сам переход от размытых требований к проверяемым сценариям, а не точность каждой предварительной оценки.
Требование овербукинга меняет модель данных
Первый вариант связывает бронь с конкретной комнатой, но не покрывает допустимое превышение числа бронирований. Поэтому модель пересматривается: резервируется тип номера, а таблица Inventory хранит общее и занятое количество по отелю, типу и дате. Бронь получает состояние, поскольку резервирование и успешная оплата происходят не одновременно. Этот пример показывает, как проверка требований меняет уже нарисованную схему.
Критическая операция должна согласованно создать бронь и увеличить занятое количество на нужные даты. Размещение этих данных в одной реляционной базе позволяет объединить изменения в транзакцию. Однако сама транзакция не снимает вопрос конкурентного доступа: два клиента могут одновременно претендовать на последние доступные места. Требуется отдельно выбрать способ защиты ограничения и поведение при конфликте.
Конкурентность и незавершённые вопросы нужно назвать явно
Разбор сравнивает пессимистические блокировки, оптимистический подход и ограничения базы данных. Первый заставляет конкурирующие операции ждать; второй требует обработки конфликтов и повторов. Автор склоняется к оптимистическому варианту для предположенной нагрузки, оговаривая его зависимость от частоты конфликтов. Масштабирование обсуждается через разделение данных по времени или отелю, поскольку гостиницы в этой модели относительно независимы.
Отдельными темами остаются согласование бронирования с внешним списанием денег и повторные запросы клиента после потери ответа. Без их проработки схему нельзя считать полным проектом промышленной системы. Статья прямо признаёт, что за время интервью закрыты не все требования. Для оценки кандидата важны итеративное рассуждение, обнаружение пробелов и объяснение компромиссов, а не видимость окончательного решения каждого возможного случая.
Что стоит унести с собой
- 01Границы, сценарии и приблизительная нагрузка должны появиться до выбора компонентов.
- 02Овербукинг требует учитывать доступность по типам номеров и датам, а не только отдельные комнаты.
- 03Конфликты бронирования, оплата и повторные запросы требуют явного решения; учебная схема не закрывает их автоматически.