Booking — це набір правил, а не “форма з датами”
У travel продукті все тримається на доступності та правилах. Один некоректний інваріант — і ви або продаєте те, чого немає, або блокуєте продажі на піку сезону.
1) Модель доступності
- Inventory по датах: roomType/ресурс → кількість.
- Блокування: maintenance, owner stays, stop‑sell.
- Резерви з TTL: щоб “тримати” номер на час оплати.
2) Прайсинг і сезони
- Сезонні правила + weekday/weekend.
- Мінімальні ночі, blackout dates, промо‑коди.
3) Політики скасування
Політика — частина продукту: дедлайни, штрафи, часткові повернення, “no‑show”. Це має бути чітко в UI і в станах бекенду.
4) Надійність і помилки
Валідація правил на сервері, ідемпотентність бронювання/оплати, “людяні” помилки і логування для підтримки.
Підсумок
Коли доступність, прайсинг і політики описані як система правил і станів, travel‑бронювання стабільне і конвертує навіть на піках.