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

Технічні виклики при бронюванні ресурсів

Уявіть: клієнт намагається забронювати переговорну на 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 (документація PostgreSQL) гарантує відсутність перетинів навіть при паралельних запитах. В одному проєкті ми скоротили час перевірки з 2 секунд до 50 мілісекунд завдяки індексам на діапазонному типі. Система витримує навантаження 5000 бронювань на день.

Чому потрібен буфер між бронюваннями?

Зали часто потребують часу на прибирання або підготовку. Ми реалізуємо це як налаштування ресурсу:

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 робочих днів. Типова вартість кастомної розробки — від $2000 до $5000 в залежності від складності. Автоматизація скорочує час адміністрування на 70% порівняно з ручним веденням.

Напишіть нам для консультації — оцінка проєкту безкоштовна. Ми врахуємо всі нюанси вашого проєкту. Звертайтеся до нас за кастомною розробкою.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

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

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

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

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

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

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.