Бронирование ресурсов на сайте: залы, комнаты, оборудование

Технические вызовы при бронировании ресурсов

Представьте: клиент пытается забронировать переговорную на 15:00, а администратор уже подтвердил другую бронь на тот же час. Система молчит — двойная запись, скандал. Мы сталкивались с этим десятки раз. Поэтому при разработке закладываем механизмы, исключающие конфликты на уровне базы данных. Ни один готовый плагин не даёт такой гибкости, как кастомное решение. По нашей статистике, количество конфликтов снижается на 90%. При этом важно контролировать не только пересечение времени, но и количество одновременно используемых единиц — особенно для оборудования. Комплектация ресурсов (зал + проектор) требует отдельной логики, когда бронь создаётся сразу на несколько ресурсов с общей целью.

Ключевое отличие от бронирования человека: один ресурс может бронироваться несколькими людьми одновременно. Например, три проектора — три разных брони. А некоторые ресурсы доступны только в комплекте: зал + оборудование.

Типы ресурсов и их особенности

Как избежать конфликтов бронирования?

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

CREATE TABLE bookable_resources ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, resource_type VARCHAR(50), capacity INTEGER DEFAULT 1, -- количество единиц (3 проектора → 3) min_duration INTERVAL DEFAULT '1 hour', max_duration INTERVAL, slot_step INTERVAL DEFAULT '30 minutes', advance_booking INTERVAL DEFAULT '1 day', max_lookahead INTERVAL DEFAULT '90 days', location VARCHAR(255), amenities TEXT[], images JSONB DEFAULT '[]', is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE bookings ( id BIGSERIAL PRIMARY KEY, resource_id INTEGER REFERENCES bookable_resources(id), quantity SMALLINT DEFAULT 1, starts_at TIMESTAMP NOT NULL, ends_at TIMESTAMP NOT NULL, status VARCHAR(20) DEFAULT 'pending', booker_name VARCHAR(255), booker_email VARCHAR(255), purpose TEXT, attendees_count INTEGER, metadata JSONB ); 

-- Сколько единиц ресурса занято в запрошенный интервал SELECT COALESCE(SUM(quantity), 0) AS booked_qty FROM bookings WHERE resource_id = $1 AND status NOT IN ('cancelled') AND tsrange(starts_at, ends_at, '[)') && tsrange($2::timestamp, $3::timestamp, '[)'); 

Если booked_qty + requested_quantity <= capacity — слот доступен. Использование диапазонных типов PostgreSQL гарантирует отсутствие пересечений даже при параллельных запросах. В одном проекте мы сократили время проверки с 2 секунд до 50 миллисекунд за счёт индексов на диапазонном типе.

Почему нужен буфер между бронями?

Залам часто требуется время на уборку или подготовку. Мы реализуем это как настройку ресурса:

CLEANUP_BUFFER = timedelta(minutes=30) def get_effective_booked_intervals(resource_id: int, date: date) -> list[Interval]: raw = get_bookings(resource_id, date, status_not_in=['cancelled']) return [ Interval( start=b.starts_at - CLEANUP_BUFFER, end=b.ends_at + CLEANUP_BUFFER, ) for b in raw ] 

На фронте для залов удобнее всего Week view с колонками по ресурсам:

Для реализации используем FullCalendar resourceTimeGrid view с кастомным backend:

calendar = new FullCalendar.Calendar(el, { plugins: ['resourceTimeGrid'], initialView: 'resourceTimeGridDay', resources: '/api/rooms', events: '/api/bookings', selectable: true, select: (info) => openBookingModal(info), }); 

Сравнение: готовый плагин vs кастомная разработка

Конфигурация в CMS

Администратор настраивает через интерфейс:

• Часы работы по дням недели
• Праздничные и нерабочие дни (blackout dates)
• Минимальный и максимальный срок бронирования
• Требуется ли подтверждение или бронь автоматическая
• Правила отмены (за сколько часов можно отменить бесплатно)

Типичные ошибки при проектировании бронирования

1. Игнорирование временных зон. Если сервер и клиент в разных часовых поясах, брони могут сместиться. Храните время в UTC и конвертируйте на фронте.
2. Отсутствие блокировок при параллельных запросах. Даже при проверке capacity возможна гонка. Используйте SELECT ... FOR UPDATE или оптимистичные блокировки.
3. Неучёт буфера между бронями. Если не добавить время на уборку, следующий клиент столкнётся с грязной комнатой. Настройте буфер как параметр ресурса.
4. Слишком сложный календарь. Пользователь должен быстро найти свободный слот. Не перегружайте интерфейс — достаточно Week view для залов и Day view для оборудования.

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

• Аналитика: разбор типов ресурсов, сценариев использования, интеграций
• Проектирование схемы БД и API
• Реализация модуля бронирования с проверкой доступности и буфером
• Разработка календарного UI (Week view / Month view)
• Интеграция с CMS (WordPress, Drupal, Laravel, Strapi или любой другой)
• Тестирование на конфликты и нагрузку (гарантируем отсутствие двойных записей)
• Документация API и инструкции для администраторов
• Поддержка после запуска (2 недели бесплатно)

Процесс работы

1. Аналитика — выявление всех типов ресурсов, правил бронирования, нештатных ситуаций
2. Проектирование — схема данных, API endpoints (REST/GraphQL), архитектура фронта
3. Реализация — бэкенд (Laravel, Node.js или Django), фронтенд (React/Vue с FullCalendar)
4. Тестирование — unit-тесты на логику конфликтов, нагрузочное тестирование (имитация 1000+ броней в час)
5. Деплой — на ваш сервер или облако (AWS, Vercel, Selectel)

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

Бронирование одного типа ресурса с базовым управлением — 5–7 рабочих дней. Несколько типов, capacity-aware проверка, буфер, календарный UI, управление исключениями в CMS — 8–12 рабочих дней. Обратитесь к нам за кастомной разработкой — мы учтём все нюансы вашего проекта. Свяжитесь с нами, чтобы обсудить детали.