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

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

Представьте: гость бронирует номер через 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 рабочих дня.

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

Услуги бэкенд-разработки: Laravel, Node.js, Go, Django, PostgreSQL

На production-сервере в 3:14 ночи очередь Laravel Jobs перестала обрабатываться. 40 000 необработанных задач в Redis. Причина: worker упал из-за memory leak в одном из Jobs (утечка через статическую переменную в Eloquent observer), supervisor не перезапустил его из-за misconfigured stopwaitsecs. Это не гипотетический сценарий — это вторник. Мы разбирали такой инцидент на проекте с нагрузкой 500 RPS: диагностика заняла 4 часа, фикс — 20 минут. Чтобы вы не теряли деньги на простоях, предлагаем услуги бэкенд-разработки с акцентом на production-grade надёжность. Оценим ваш проект за 2 дня.

Backend — это то, что работает когда никто не смотрит. Или не работает. Гарантируем, что у вас будет первый вариант.

Что мы делаем с первого дня правильно

Service Layer поверх Fat Controllers. Controller получает HTTP-запрос, валидирует его через Form Request, передаёт данные в Service, возвращает ответ. Бизнес-логика в Service, не в Controller. Это звучит банально, но большинство legacy-проектов — это контроллеры по 500 строк с SQL-запросами внутри.

Repository Pattern используем осторожно. Если вы просто оборачиваете Model::where(...) в метод репозитория — это бойлерплейт без пользы. Repository оправдан когда: нужно абстрагироваться от источника данных (БД + кеш + внешний API) или когда логика запросов достаточно сложна для изоляции.

Jobs, Events, Listeners. Всё, что можно сделать асинхронно — делаем асинхронно. Отправка email, генерация PDF, синхронизация с внешним API, пересчёт агрегатов — в Queue. Laravel Horizon для мониторинга очередей в Redis: видно throughput, failed jobs, время обработки по очередям.

Как Octane справляется с высокой нагрузкой

Laravel Octane с RoadRunner или Swoole держит приложение в памяти между запросами — убирает overhead bootstrap (загрузка конфигов, автозагрузка классов) на каждый HTTP-запрос. Прирост: 3–8x на синтетических бенчмарках, 2–4x на реальных приложениях. Важно: нельзя хранить состояние между запросами в статических переменных — это приводит именно к таким инцидентам, как в начале. Применяем это в проектах с >1000 RPS.

Что делать с N+1 запросами

N+1 — самая распространённая причина медленных страниц в Laravel-приложениях. Стандартная история: страница работала нормально на dev с 10 записями, на production с 10 000 — 8-секундная загрузка.

Laravel Debugbar в dev-окружении показывает количество запросов на страницу. Более 20 запросов на одну страницу — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профилирования в staging: логирует все запросы, jobs, mail, notifications с детализацией по времени. Цифры: после внедрения eager loading время загрузки страницы падает с 8 с до 0.3 с — в 27 раз.

PostgreSQL: индексы, которые реально нужны

PostgreSQL 14+ — основная БД на всех проектах. Используем связку PgBouncer + PostgreSQL. Опыт 10+ лет, более 50 backend-проектов, 5 лет на рынке.

Как PostgreSQL помогает избежать медленных запросов

Composite indexes для частых WHERE + ORDER BY. Если у вас WHERE user_id = ? AND status = ? ORDER BY created_at DESC — нужен (user_id, status, created_at DESC). Индекс по (user_id) отдельно плохо помогает с сортировкой.

Partial indexes. Если 95% запросов идут по WHERE status = 'active':

CREATE INDEX idx_orders_active ON orders (created_at DESC)
WHERE status = 'active';

Индекс маленький, быстрый, покрывает основную нагрузку.

GIN-индексы для JSONB и массивов. @> оператор без GIN-индекса — seq scan. С индексом — быстро даже на миллионах записей.

GIN для full-text search. to_tsvector + GIN вместо LIKE '%query%'. LIKE без индекса — всегда seq scan. С pg_trgm extension и gin_trgm_ops — поддержка LIKE с индексом, полезно для CRM-поиска по частичному совпадению.

Connection pooling: почему важнее чем кажется

Rails, Laravel, Django открывают новое соединение с PostgreSQL на каждый PHP/Python процесс. На 100 воркерах — 100 соединений. PostgreSQL начинает деградировать от 200–300 активных соединений — overhead на управление соединениями становится значительным.

PgBouncer — connection pooler перед PostgreSQL. Режим transaction pooling: соединение с PostgreSQL занято только на время транзакции, между запросами возвращается в пул. 1000 приложений-воркеров → 20–50 реальных соединений к PostgreSQL. Это снижает latency на 40% и уменьшает затраты на хостинг на 30%.

Node.js с Fastify: когда это лучше Laravel

Node.js оправдан для:

• Realtime: WebSocket-серверы, Server-Sent Events, чат, live-обновления
• Streaming: большие файлы, видео, данные потоком
• High I/O concurrency: много параллельных запросов к внешним API без тяжёлой бизнес-логики
• Serverless: Lambda/Cloud Functions — Node.js стартует быстрее PHP

Fastify вместо Express: в 2–3 раза быстрее на benchmarks, встроенная JSON Schema валидация, лучшая TypeScript поддержка, plugin-архитектура.

Типичная архитектура realtime: Laravel — основная бизнес-логика и REST API. Node.js + Socket.io или ws — WebSocket сервер. Laravel публикует события в Redis Pub/Sub, Node.js подписывается и транслирует клиентам. Это разделение позволяет масштабировать WebSocket-сервер независимо от основного приложения.

Go: микросервисы и высокая нагрузка

Go используем для:

• Высоконагруженных микросервисов (> 10 000 RPS)
• Фоновых воркеров с жёсткими требованиями к latency
• Инструментов DevOps и CLI
• gRPC-сервисов в микросервисной архитектуре

Goroutines — дешевле OS-потоков в тысячи раз. 10 000 конкурентных соединений на Go — норма на одном сервере.

Но Go — не волшебная таблетка. Разработка медленнее чем на Laravel: больше бойлерплейта, нет ORM уровня Eloquent, обработка ошибок через if err != nil везде. Оправдан только когда производительность — реальное требование, не предположение.

Django и Python backend

Django с DRF (Django REST Framework) — для задач где нужен Python: ML-пайплайны, обработка данных, интеграции с AI-инструментами.

Celery для фоновых задач — аналог Laravel Queue, но сложнее в конфигурации. Celery Beat для cron-задач.

Django ORM vs raw SQL: ORM удобен для CRUD. Для аналитических запросов с несколькими JOIN, оконными функциями и CTE — connection.execute() с raw SQL читаемее и предсказуемее.

Redis: не только кеш

Redis в наших проектах выполняет несколько ролей:

Redis Cluster для горизонтального масштабирования. Sentinel для автоматического failover на standalone установках.

Деплой и инфраструктура

Docker + docker-compose — стандарт для локальной разработки и production. Каждый сервис в контейнере: PHP-FPM/Octane, Nginx, PostgreSQL, Redis, Queue Worker, Scheduler.

CI/CD через GitHub Actions:

1. Прогон тестов (PHPUnit / Pest, Vitest, Playwright)
2. Сборка Docker-образа
3. Push в Container Registry
4. Deploy: docker pull → docker-compose up -d на сервере, или Kubernetes rolling update

Zero-downtime deploy для Laravel: php artisan down --secret=TOKEN не нужен при правильной настройке. Стратегия: новый контейнер стартует рядом со старым, Nginx переключает трафик после health check, старый контейнер останавливается.

Мониторинг: Sentry для exception tracking с alerting в Slack/Telegram. Grafana + Prometheus (или Grafana Cloud) для метрик: CPU, memory, request rate, queue depth, database connection count. Алерт на: error rate > 1%, p99 latency > 2s, queue depth > 1000 jobs.

Что входит в работу под ключ

• Архитектурное проектирование (документация API, схема БД, диаграмма сервисов)
• Реализация по согласованному ТЗ с code review
• Настройка CI/CD, мониторинга, алертинга
• Нагрузочное тестирование (k6, wrk) с отчётом
• Передача исходников, доступов, инструкция по деплою
• Обучение команды заказчика (2-3 сессии)
• Гарантийная поддержка 1 месяц после сдачи

Ориентиры по срокам

Стоимость рассчитывается индивидуально после анализа требований к нагрузке, интеграциям и бизнес-логике. Типичный бюджет backend-проекта — от 500 000 до 2 000 000 рублей в зависимости от сложности. Свяжитесь с нами для бесплатного аудита вашего текущего backend — получите план оптимизации за 2 дня. Закажите консультацию.