Описать структуру таблиц, чтобы можно было понять, свободен ли номер на выбранные даты. Написать SQL запрос и обсудить его произвоительность. Как поддержать условие 10% овербукинга?
Как предотвратить проблемы при одновременной попытке забукать один тип комнаты двумя клиентами, когда таких комнат уже не осталось?
pessimistic lock
optimistic lock
database constraints
Как недопустить проблем при многократном нажатии на кнопку создания заказа?
Показывать страницу создания заказа с уникальным reservation_id в url.
Как будем масштабироваться, если наш сервис выростет до уровня букинга?
Все наши сервисы stateless, легко масштабируются. БД можем шардировать по ключу = локация
Можем вынести данные об оставшихся номерах в key-value, для быстрого чтения. Но при создании заказа дополнительно проверять доступность в БД. Кэш key: hotelId_roomTypeId_date, value: количество доступных номеров Обновлять кэш можно через CDC решение БД —> key-value
Используем реляционную БД. Нам нужны ACID гарантии, чтобы проще справляться с конкуренцией между клиентами. Плюс наша система скорее read-heavy, чем write-heavy. Что неплохо ложиться на реляционные БД.
