Разработка системы бронирования номеров отеля на сайте

Реализация бронирования номеров отеля на сайте

Представьте: гость бронирует номер через Booking.com, а администратор одновременно продаёт его напрямую. Результат — овербукинг, недовольный клиент и испорченная репутация. Мы решаем эту проблему с помощью системы, которая синхронизирует все каналы в реальном времени. Наш опыт — 7+ лет, более 30 внедрённых проектов. Гарантируем отсутствие двойных бронирований и корректную синхронизацию с внешними каналами.

Отельное бронирование — одна из самых сложных задач резервирования. Гости приезжают на несколько ночей, тарифы меняются в зависимости от сезона, а правила отмены могут быть разными. Система должна работать с диапазонами дат, а не с отдельными днями. Основные проблемы: утечка номеров между разными каналами продаж, неверный расчёт цены при смене тарифа, сложное управление разными типами комнат. Наш подход решает их с помощью схемы БД с exclusion constraints и гибкой системы тарифов.

Почему бронирование отелей — сложная задача?

Как избежать двойного бронирования?

На практике мы используем два уровня защиты. Во-первых, база данных — exclusion constraint на таблице бронирований не даёт создать пересекающиеся записи. Во-вторых, приложение перед созданием брони проверяет доступность через отдельный запрос. Это исключает race condition даже при высокой нагрузке. Например, если два гостя одновременно бронируют последний номер одного типа, система обработает запросы последовательно и только один подтвердит бронь.

В одном из проектов для сети отелей мы внедрили подобную систему. До этого они теряли до 5% броней из-за двойных продаж. После внедрения исключения на уровне БД и автоматической синхронизации с Booking.com и Airbnb за месяц не было ни одного овербукинга. Время на обработку каждой брони сократилось с 3 минут до 30 секунд.

Как мы реализуем проект: пошаговый план

1. Аудит требований и интеграций. Фиксируем список OTA, PMS, типы номеров и тарифы.
2. Проектирование схемы и API. Создаём модель данных с exclusion constraints и эндпоинты для фронтенда.
3. Разработка модулей бронирования и тарифов. Реализуем поиск, расчёт стоимости, отмену.
4. Интеграция с OTA через Channel Manager. Настраиваем iCal или OTA XML в зависимости от канала.
5. Тестирование и отладка. Проверяем нагрузочное тестирование (до 1000 запросов/сек) и сценарии двойного бронирования.
6. Деплой и обучение персонала. Разворачиваем на сервере, проводим обучение администраторов.

Модель данных

CREATE TABLE room_types ( id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, description TEXT, max_occupancy SMALLINT NOT NULL, area_sqm NUMERIC(5,1), amenities TEXT[], images JSONB DEFAULT '[]', base_price NUMERIC(10,2) ); CREATE TABLE rooms ( id SERIAL PRIMARY KEY, room_type_id INTEGER REFERENCES room_types(id), room_number VARCHAR(10) NOT NULL, floor SMALLINT, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE rate_plans ( id SERIAL PRIMARY KEY, room_type_id INTEGER REFERENCES room_types(id), name VARCHAR(100), price NUMERIC(10,2), valid_from DATE NOT NULL, valid_until DATE NOT NULL, min_stay_nights SMALLINT DEFAULT 1, cancellation_hours INTEGER DEFAULT 24, is_refundable BOOLEAN DEFAULT TRUE, includes_breakfast BOOLEAN DEFAULT FALSE ); CREATE TABLE reservations ( id BIGSERIAL PRIMARY KEY, room_id INTEGER REFERENCES rooms(id), room_type_id INTEGER, rate_plan_id INTEGER REFERENCES rate_plans(id), check_in DATE NOT NULL, check_out DATE NOT NULL, adults SMALLINT DEFAULT 1, children SMALLINT DEFAULT 0, guest_name VARCHAR(255) NOT NULL, guest_email VARCHAR(255) NOT NULL, guest_phone VARCHAR(50), total_amount NUMERIC(12,2), status VARCHAR(20) DEFAULT 'pending', payment_status VARCHAR(20) DEFAULT 'unpaid', notes TEXT, source VARCHAR(30) DEFAULT 'website', external_id VARCHAR(100), created_at TIMESTAMP DEFAULT NOW(), CONSTRAINT no_room_overlap EXCLUDE USING gist ( room_id WITH =, daterange(check_in, check_out, '[)') WITH && ) WHERE (status NOT IN ('cancelled', 'no_show')) ); 

Поиск доступных номеров

def search_available_rooms(check_in: date, check_out: date, adults: int, children: int = 0): nights = (check_out - check_in).days guests = adults + children return db.fetchall(""" SELECT rt.*, COUNT(r.id) AS available_count, rp.price AS nightly_price, rp.price * %(nights)s AS total_price, rp.is_refundable, rp.includes_breakfast, rp.min_stay_nights FROM room_types rt JOIN rooms r ON r.room_type_id = rt.id AND r.is_active = TRUE JOIN rate_plans rp ON rp.room_type_id = rt.id AND rp.valid_from <= %(check_in)s AND rp.valid_until >= %(check_out)s AND rp.min_stay_nights <= %(nights)s WHERE rt.max_occupancy >= %(guests)s AND r.id NOT IN ( SELECT room_id FROM reservations WHERE status NOT IN ('cancelled', 'no_show') AND daterange(check_in, check_out, '[)') && daterange(%(check_in)s, %(check_out)s, '[)') ) GROUP BY rt.id, rp.id HAVING COUNT(r.id) > 0 ORDER BY rp.price ASC """, {'check_in': check_in, 'check_out': check_out, 'nights': nights, 'guests': guests}) 

Динамическое ценообразование

Цена за ночь может меняться в зависимости от дня недели, загруженности, сезона. Реализуем расчёт с пониточной итерацией:

def calculate_total_price(room_type_id: int, check_in: date, check_out: date) -> Decimal: total = Decimal(0) current = check_in while current < check_out: rate = get_rate_for_date(room_type_id, current) if rate is None: raise NoRateAvailable(f"No rate for {current}") total += rate.price current += timedelta(days=1) return total def get_rate_for_date(room_type_id: int, d: date) -> Optional[RatePlan]: return db.fetchone(""" SELECT * FROM rate_plans WHERE room_type_id = %s AND valid_from <= %s AND valid_until >= %s ORDER BY price DESC LIMIT 1 """, [room_type_id, d, d]) 

Интеграция с Channel Manager / OTA

Для синхронизации с Booking.com, Expedia, Airbnb используется Channel Manager (TravelLine, Bnovo, Wubook). Стандартный протокол — OTA XML (OpenTravel Alliance) или iCal для простых случаев. Channel Manager — система для управления каналами продаж. Наше решение обрабатывает до 1000 запросов в секунду, что вдвое быстрее типовых решений на WordPress.

iCal-синхронизация для Airbnb:

def generate_ical_feed(room_id: int) -> str: bookings = get_confirmed_bookings(room_id) cal = Calendar() cal.add('prodid', '-//Hotel Booking//EN') cal.add('version', '2.0') for b in bookings: event = Event() event.add('uid', f"booking-{b.id}@hotel.example.com") event.add('dtstart', b.check_in) event.add('dtend', b.check_out) event.add('summary', 'BLOCKED') cal.add_component(event) return cal.to_ical().decode('utf-8') 

Отмена и возврат

def cancel_reservation(reservation_id: int, initiator: str) -> dict: res = get_reservation(reservation_id) hours_to_arrival = ( datetime.combine(res.check_in, time(14, 0)) - datetime.utcnow() ).total_seconds() / 3600 rate = get_rate_plan(res.rate_plan_id) if rate.is_refundable and hours_to_arrival >= rate.cancellation_hours: refund_amount = res.total_amount refund_type = 'full' elif not rate.is_refundable: refund_amount = Decimal(0) refund_type = 'none' else: refund_amount = res.total_amount * Decimal('0.5') refund_type = 'partial' process_refund(res.payment_id, refund_amount) update_reservation_status(reservation_id, 'cancelled', initiator) send_cancellation_email(res, refund_amount, refund_type) return {'refund': refund_amount, 'type': refund_type} 

Что входит в работу

• Архитектура и проектирование схемы БД (PostgreSQL с exclusion constraints).
• Реализация модулей: поиск, бронирование, ценообразование, отмена.
• Интеграция с внешними системами (PMS, OTA) через iCal или OTA XML.
• Написание тестов (unit, integration) и документации.
• Обучение персонала работе с системой.
• Гарантийная поддержка 3 месяца.

Сроки реализации

Базовый модуль без динамических тарифов и без PMS-интеграции — 10–13 рабочих дней. Динамическое ценообразование, назначение номеров, iCal-синхронизация, управление тарифными планами, личный кабинет гостя — 16–22 рабочих дня.

Оцените выгоду интеграции — свяжитесь с нами для предварительного аудита. Закажите консультацию — мы оценим ваш проект под ключ и предложим оптимальный стек.