Гостиница: синхронизация с агрегаторами со своей стороны, а не по тарифу за номер

MAATRIX

Гостиница подключает к площадкам бронирования десять номеров — платит за десять. Открывает второй корпус, доводит номерной фонд до тридцати — счёт за канал-менеджер вырастает пропорционально, хотя объём реальной синхронизации (пара запросов на номер в сутки) вырос совсем не так драматично, как цена. Дальше — филиал во втором городе, и тариф удваивается ещё раз. К концу августа 2026 года это по-прежнему стандартная модель на рынке: плата привязана не к тому, сколько данных реально гоняется туда-обратно, а к числу подключённых номеров. Разберём, что на самом деле происходит при синхронизации с агрегаторами, и как перенести эту работу на собственный сервер с фиксированной стоимостью — независимо от того, десять у вас номеров или двести.

Что стоит за тарифом «за номер»

Канал-менеджер решает одну задачу: держит доступность, цены и ограничения по датам одинаковыми во всех точках продаж одновременно, чтобы гостиница не продала один и тот же номер дважды через разные площадки. Технически это цикл из двух потоков: вы (или ваша система управления номерным фондом) отдаёте наружу состояние по каждой дате — свободно или занято, цена, минимальный срок проживания, закрыт ли заезд или выезд на конкретный день — а с площадок обратно прилетают бронирования, которые нужно тут же зафиксировать у себя, чтобы не продать номер повторно.

Сама по себе эта задача не тяжёлая по объёму данных: несколько сотен или тысяч записей в сутки даже для крупной гостиницы — это доли мегабайта трафика. Но коммерческая модель большинства готовых решений построена не на объёме передаваемых данных, а на числе подключённых номеров — потому что так проще продавать и предсказывать выручку поставщику сервиса. В результате гостиница платит за количество единиц номерного фонда, а не за то, сколько реально стоит вычислительно поддерживать синхронизацию. Для небольшой гостиницы это может быть незаметно. Для сети мини-отелей или гостиницы, которая планирует расти, плата «за номер» превращается в статью расходов, растущую линейно вместе с бизнесом, — притом что предельная стоимость обслуживания дополнительного номера в самой синхронизации близка к нулю.

Что на самом деле нужно синхронизировать

Прежде чем говорить об альтернативе, стоит разложить задачу на составляющие — так понятнее, что именно можно взять на себя:

• Доступность (availability) — свободен номер на конкретную дату или нет, по каждому типу номера отдельно.
• Цена (rate) — стоимость за ночь, часто с разбивкой по типу тарифа (с завтраком, без возврата, для раннего бронирования).
• Ограничения (restrictions) — минимальный срок проживания, закрытие даты для заезда или выезда, стоп-продажа на конкретный день.
• Входящие брони — событие с площадки о том, что номер забронирован, с датами, контактами гостя и суммой.
• Отмены и изменения — гость передумал, изменил даты, площадка прислала обновление.

Первые три пункта — это то, что вы отдаёте наружу. Последние два — то, что должно приходить к вам и мгновенно отражаться в общей картине занятости, иначе следующий проданный номер на те же даты станет овербукингом. Именно поэтому синхронизация не терпит задержек и ручной работы: цикл должен быть замкнут автоматически и работать без выходных.

Синхронизация со своей стороны: что меняется технически

Идея «своей стороны» простая: вместо того чтобы платить стороннему каналу-менеджеру за то, что он опрашивает площадки и прокидывает данные, этот цикл выполняет небольшой сервис на вашем собственном сервере. Крупные площадки бронирования обычно публикуют партнёрские интерфейсы для подключения (документированные API, экспорт и импорт данных о доступности), и подключение к ним — это вопрос разработки один раз, а не абонентской платы каждый месяц за каждый номер.

Практическая архитектура выглядит так:

1. Источник истины — таблица номеров, дат и цен в вашей базе данных на сервере. Всё остальное синхронизируется относительно неё.
2. Исходящий воркер — процесс, который по расписанию (или по событию изменения цены/доступности) отправляет обновления на каждую подключённую площадку.
3. Входящий приёмник — эндпоинт, который принимает уведомления о новых бронированиях и отменах и сразу же блокирует занятые даты в источнике истины.
4. Журнал операций — лог каждого отправленного и полученного события, чтобы при разборе спорной ситуации («почему номер продался дважды») было видно, что и когда происходило.

Здесь возникает тот же архитектурный вопрос, что и в других задачах доставки событий: получать уведомления по запросу к площадке (поллинг) или ждать, пока площадка сама пришлёт уведомление (вебхук). У площадок бронирования обычно поддерживаются оба варианта, и выбор между ними — тот же компромисс между задержкой и нагрузкой, что разбирался в статье про выбор между вебхуком и поллингом: вебхук даёт бронь почти мгновенно, но требует постоянно доступного публичного эндпоинта; поллинг проще в развёртывании, но вносит задержку между «гость забронировал» и «у вас в системе номер помечен занятым».

Минимальная схема таблицы доступности на PostgreSQL, вокруг которой строится вся логика:

CREATE TABLE room_availability (
    room_type_id INT NOT NULL,
    stay_date DATE NOT NULL,
    is_available BOOLEAN NOT NULL DEFAULT true,
    rate_cents INT NOT NULL,
    min_stay SMALLINT NOT NULL DEFAULT 1,
    closed_to_arrival BOOLEAN NOT NULL DEFAULT false,
    closed_to_departure BOOLEAN NOT NULL DEFAULT false,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    PRIMARY KEY (room_type_id, stay_date)
);

CREATE TABLE sync_log (
    id BIGSERIAL PRIMARY KEY,
    channel TEXT NOT NULL,
    direction TEXT NOT NULL,      -- 'out' | 'in'
    payload JSONB NOT NULL,
    status TEXT NOT NULL,         -- 'ok' | 'error' | 'pending'
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Изменение любой строки в room_availability — событие, которое ставится в очередь на отправку на все подключённые площадки. Такое разделение «источник истины отдельно, доставка на каждый канал отдельно» экономит массу нервов, когда каналов становится больше одного: логика продажи и логика синхронизации не переплетаются.

Очередь и повторные попытки вместо ручного контроля

Сеть между вашим сервером и площадкой бронирования не идеальна: запрос может уйти в таймаут, площадка — вернуть временную ошибку, у неё самой может идти техническое обслуживание. Если отправка обновлений реализована как простой синхронный вызов «отправили и забыли», часть изменений цены или закрытия дат будет теряться молча — и вы узнаете об этом только тогда, когда гость увидит на площадке старую (неверную) цену или забронирует уже занятый номер.

Правильная схема — не прямой вызов API из места, где меняется цена, а постановка события в очередь с гарантированной обработкой и повторными попытками при ошибке. Общий принцип такой же, как в любой системе с очередями сообщений, — устройство и подводные камни разобраны в статье как устроена очередь сообщений. Применительно к синхронизации с агрегаторами это выглядит так:

def push_update(channel, room_type_id, stay_date, attempt=1):
    payload = build_payload(room_type_id, stay_date)
    try:
        response = channel.send(payload, timeout=10)
        response.raise_for_status()
        log_sync(channel.name, "out", payload, "ok")
    except (Timeout, HTTPError) as e:
        log_sync(channel.name, "out", payload, "error")
        if attempt < 5:
            delay = min(60, 2 ** attempt)
            schedule_retry(push_update, delay, channel, room_type_id, stay_date, attempt + 1)
        else:
            alert_ops(f"Синхронизация {channel.name} не проходит 5 попыток подряд: {room_type_id}/{stay_date}")

Экспоненциальная задержка между попытками и алерт после исчерпания лимита — не украшение, а обязательная часть системы. Без него единственный способ узнать о проблеме — жалоба гостя на ресепшене.

Входящий поток (брони с площадок) требует ещё и идемпотентности: одна и та же бронь иногда прилетает повторно (сетевой сбой на стороне площадки, повторная отправка вебхука). Обработчик должен проверять внешний идентификатор брони и не создавать дубликат, если такая запись уже есть в базе — иначе номер может оказаться заблокирован дважды или, наоборот, освобождён по ошибке при повторной обработке отмены.

Что делать, если данные всё-таки разошлись

Даже с очередью и повторными попытками полностью исключить рассинхрон нельзя — слишком много независимых сторон в цепочке. Реалистичная цель не «никогда не ошибаться», а «быстро заметить и не потерять бронь гостя». Практические меры:

• Сверка раз в сутки. Отдельная задача по ночам сравнивает доступность в вашей базе с тем, что реально отдаётся на каждой площадке, и логирует расхождения — это дешевле, чем ловить овербукинг постфактум.
• Очередь ручного разбора. Если пришла бронь на дату, которая у вас уже помечена занятой (гость мог позвонить напрямую или забронировать через другую площадку раньше, чем ушло обновление), система не должна молча отклонять или молча принимать её — событие должно попасть в отдельный список для администратора с полным контекстом обеих броней.
• Буфер на количество номеров, а не на проценты интуитивно. Некоторые гостиницы держат один-два номера в буфере на пиковые даты именно из-за задержки синхронизации — это не решает проблему архитектурно, но снижает цену ошибки, пока система обкатывается.
• Резервные копии базы бронирований. База с датами заезда и контактами гостей — это то, что нельзя потерять или испортить неудачной миграцией. Автоматизация регулярных копий разобрана в статье про резервное копирование баз данных, и для гостиницы это не необязательный пункт, а часть той же системы, что и сама синхронизация.

Экономика: фиксированный сервер против растущей платы за номер

Смена модели меняет структуру расходов, а не только их размер. У готового канала-менеджера стоимость растёт вместе с числом номеров и часто — с числом подключённых площадок: правило простое, но неудобное для растущего бизнеса. У собственного решения стоимость — это цена сервера, на котором крутится сервис синхронизации и база данных, и она не зависит от того, десять у вас номеров или сто пятьдесят. Разница особенно заметна не в моменте, а на горизонте роста: гостиница, которая расширяется, наращивает номерной фонд или открывает второй объект, продолжает платить за инфраструктуру примерно одну и ту же сумму, а не пропорционально растущую.

Это не значит, что переход бесплатен в другом смысле — за фиксированную стоимость сервера вы платите не деньгами за каждый номер, а временем разработки и последующей поддержкой: площадки бронирования время от времени меняют форматы данных или требования к интеграции, и кто-то должен следить за этими изменениями. Для гостиницы с парой номеров овчинка обычно не стоит выделки — проще заплатить за готовый канал-менеджер и не думать об этом. А вот для сети мини-отелей, гостевых домов под одним управлением или гостиницы, которая закладывает рост номерного фонда в свои планы на ближайшие пару лет, экономика довольно быстро складывается в пользу своей инфраструктуры: тот же принцип «фиксированная стоимость своей системы против растущего процента или тарифа стороннему сервису» разбирался и для смежной задачи — бронирования столов на собственном сайте ресторана, где вместо комиссии агрегатору бизнес берёт под контроль сам процесс приёма заявок.

Отдельно стоит закладывать отказоустойчивость: если синхронизация — это единственный сервер без резервирования, а он ляжет в пятницу вечером перед заездами выходного дня, цена простоя окажется куда выше сэкономленной абонентской платы. Поэтому под такую задачу разумно брать не самый дешёвый тариф, а сервер с запасом по ресурсам и понятным планом восстановления после сбоя — база бронирований и очередь синхронизации не тот случай, где стоит экономить на последней миле.

Частые вопросы