Система бронирования отелей

Постановка задачи

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

Что не включаем в этот разбор

Оценка нагрузки

Сначала полезно сделать грубую оценку (back of the envelope) нагрузки: она быстро показывает, где действительно нужен запас по масштабу, а где не стоит преждевременно усложнять архитектуру.

Базовый API

{
  "hotel_id": "123",
  "room_type_id": "456",
  "start_date": "2024-03-15",
  "end_date": "2024-03-20",
  "guest_info": { ... }
}

Эволюция модели данных

Главный вопрос здесь не в том, как хранить саму бронь, а как моделировать доступность (availability) по типу номера и по каждой дате так, чтобы проверка и обновление оставались быстрыми.

Reservation
├── id
├── hotel_id
├── room_type_id
├── room_id (конкретный номер)
├── start_date
├── end_date
├── status
└── guest_id

RoomTypeInventory
├── hotel_id
├── room_type_id
├── date
├── total_rooms (всего номеров этого типа)
├── total_reserved (забронировано)
└── overbooking_limit (лимит овербукинга)

Constraint: total_reserved <= total_rooms * (1 + overbooking_limit)

Обработка конкурентности

На критическом пути подтверждения брони важна консистентность (consistency): если два пользователя одновременно пытаются купить последний номер, система должна гарантировать, что подтверждение получит только допустимое число клиентов.

Обычно выбор идёт между пессимистической блокировкой (pessimistic locking) и оптимистической блокировкой (optimistic locking). При этом нужно смотреть не только на корректность, но и на пропускную способность (throughput) системы и вероятность того, что под пиками возникнет взаимная блокировка (deadlock).

BEGIN;
SELECT * FROM room_inventory 
WHERE hotel_id = ? AND room_type_id = ? AND date = ?
FOR UPDATE;

-- Проверяем лимит и обновляем счётчик
UPDATE room_inventory SET total_reserved = total_reserved + 1 ...

COMMIT;

-- Isolation Level: REPEATABLE READ
BEGIN;

UPDATE room_inventory 
SET total_reserved = total_reserved + 1
WHERE hotel_id = ? 
  AND room_type_id = ? 
  AND date = ?
  AND total_reserved < total_rooms * (1 + overbooking_limit);

-- Если affected_rows = 0, лимит уже исчерпан
COMMIT;

ALTER TABLE room_inventory 
ADD CONSTRAINT check_overbooking 
CHECK (total_reserved <= total_rooms * (1 + overbooking_limit));

Стратегии масштабирования

Дальше система обычно растёт по двум осям: по времени и по числу отелей. Здесь приходится заранее понимать, когда достаточно партиционирования, когда нужно шардирование (sharding), помогает ли согласованное хеширование (consistent hashing), и насколько тяжёлым станет эксплуатационное обслуживание (maintenance) старых разделов и архивов.

Ключевые выводы из интервью