Розробка системи онлайн-бронювання для сайту

Розробка системи онлайн-бронювання для сайту

Подвійне бронювання — головний біль будь-якого сервісу з розкладом. Помилка в цій зоні коштує не тільки нервів клієнтів, але й втраченої виручки — до 20% потенційних замовлень. Ми будуємо системи бронювання, які запобігають перетинам на рівні бази даних і зберігають консистентність навіть при пікових навантаженнях: до 5000 одночасних запитів на хвилину. В основі лежить комбінація PostgreSQL EXCLUDE constraint, Redis для тимчасового утримання слотів і асинхронних сповіщень. Такий підхід виключає race conditions без блокувань додатку.

Система бронювання — це не просто форма з вибором дати. Це управління слотами, перевірка доступності в реальному часі, утримання броні, обробка конкурентних запитів і ланцюжок сповіщень. Неправильна реалізація призводить до подвійних бронювань або «завислих» слотів, що підриває довіру клієнтів.

Клієнти часто стикаються з ситуацією: слот у календарі вільний, а після заповнення форми виявляється зайнятим. Або навпаки — адміністратор бачить бронь, але клієнт не отримує підтвердження. Ми усуваємо ці сценарії: прозоре блокування ресурсів, сповіщення в реальному часі, захист від дублюючих запитів.

Як влаштована перевірка доступності в реальному часі?

Проєктуємо схему даних. Ключові сутності — ресурс, розклад і бронь.

-- Ресурс бронювання (зал, спеціаліст, номер, стіл тощо)
CREATE TABLE bookable_resources (
    id SERIAL PRIMARY KEY,
    type VARCHAR(50) NOT NULL, -- 'specialist', 'room', 'table', 'car'
    name VARCHAR(255) NOT NULL,
    config JSONB,
    is_active BOOLEAN DEFAULT TRUE
);

-- Розклад доступності ресурсу
CREATE TABLE resource_schedules (
    id SERIAL PRIMARY KEY,
    resource_id INTEGER REFERENCES bookable_resources(id),
    weekday SMALLINT,
    specific_date DATE,
    start_time TIME NOT NULL,
    end_time TIME NOT NULL,
    slot_duration INTERVAL,
    is_available BOOLEAN DEFAULT TRUE
);

-- Власне бронювання
CREATE TABLE bookings (
    id BIGSERIAL PRIMARY KEY,
    resource_id INTEGER REFERENCES bookable_resources(id),
    user_id INTEGER,
    guest_name VARCHAR(255),
    guest_email VARCHAR(255),
    guest_phone VARCHAR(50),
    starts_at TIMESTAMP NOT NULL,
    ends_at TIMESTAMP NOT NULL,
    status VARCHAR(20) DEFAULT 'pending',
    notes TEXT,
    metadata JSONB,
    created_at TIMESTAMP DEFAULT NOW(),
    confirmed_at TIMESTAMP,
    cancelled_at TIMESTAMP,
    CONSTRAINT no_overlap EXCLUDE USING gist (
        resource_id WITH =,
        tsrange(starts_at, ends_at, '[)') WITH &&
    ) WHERE (status NOT IN ('cancelled'))
);

Constraint EXCLUDE USING gist — найнадійніший спосіб запобігти подвійному бронюванню на рівні БД. Він працює атомарно і не залежить від логіки додатку. PostgreSQL EXCLUDE constraint у 10 разів швидше блокувань на рівні додатку.

Чому важливо використовувати EXCLUDE constraint?

Додаток може перевіряти доступність через SELECT, але між читанням і вставкою інший запит може встигнути створити бронь. EXCLUDE constraint ловить цю гонку на рівні БД і викидає помилку ExclusionViolationError. Ми обробляємо її і повертаємо клієнту зрозуміле повідомлення. Це гарантує відсутність перетинів без розподілених блокувань. Порівняння методів:

Дані отримано при навантаженні 5000 паралельних запитів.

Алгоритм перевірки доступності

def get_available_slots(resource_id: int, date: date) -> list[TimeSlot]:
    schedule = get_schedule(resource_id, date)
    if not schedule or not schedule.is_available:
        return []
    all_slots = generate_slots(
        start=schedule.start_time,
        end=schedule.end_time,
        duration=schedule.slot_duration or timedelta(hours=1),
    )
    booked = get_booked_intervals(resource_id, date)
    return [
        slot for slot in all_slots
        if not any(slot.overlaps(b) for b in booked)
    ]

Тимчасове утримання слоту (hold)

Між вибором слоту та оплатою проходить час. Щоб слот не зайняли в цей момент, реалізуємо механізм hold на Redis. Час утримання — 10 хвилин (600 секунд).

HOLD_TTL = 600

def hold_slot(resource_id: int, starts_at: datetime, session_id: str) -> str:
    hold_key = f"hold:{resource_id}:{starts_at.isoformat()}"
    success = redis.set(hold_key, session_id, nx=True, ex=HOLD_TTL)
    if not success:
        existing = redis.get(hold_key)
        if existing and existing.decode() != session_id:
            raise SlotAlreadyHeld("Слот зайнятий іншим користувачем")
    return hold_key

def confirm_booking(hold_key: str, booking_data: dict) -> Booking:
    session_id = redis.get(hold_key)
    if not session_id:
        raise HoldExpired("Час утримання слоту вичерпано")
    with db.transaction():
        booking = create_booking(booking_data)
        redis.delete(hold_key)
    return booking

Як обробляються конкурентні запити?

Навіть з EXCLUDE constraint можлива гонка: два запити перевіряють доступність одночасно, обидва бачать слот вільним. Constraint зловить другий INSERT.

try:
    booking = create_booking(data)
except ExclusionViolationError:
    raise BookingConflict("Цей слот щойно був заброньований. Виберіть інший час.")

Сповіщення

Нагадування надсилаються через scheduled jobs.

Правила скасування та зміни

Гнучка система політик: безкоштовний період, часткове повернення, безповоротний термін. Політика зберігається на рівні ресурсу і застосовується автоматично.

Покроковий алгоритм впровадження системи бронювання

1. Аудит вимог: визначаємо типи ресурсів, кількість слотів, пікове навантаження.
2. Проєктування схеми БД: створюємо структуру таблиць з EXCLUDE constraint.
3. Налаштування Redis hold: утримання слотів з TTL 10 хвилин.
4. Розробка API: CRUD для ресурсів, розкладу, броней.
5. Інтеграція з платіжним шлюзом: Stripe з ручним захопленням коштів.
6. Ланцюжок сповіщень: Email через SMTP, SMS через API провайдера.
7. Адміністративна панель: управління бронями на React/Vue.
8. Навантажувальне тестування: перевірка при 5000 паралельних запитів.
9. Документація та навчання.

Що входить в роботу

• Проєктування схеми даних і вибір стеку (PostgreSQL, Redis, Python/Node.js)
• Реалізація CRUD API для ресурсів, розкладу та броней
• Механізм hold на Redis з автоматичним зняттям по TTL
• Інтеграція з платіжним шлюзом (Stripe або інший)
• Налаштування ланцюжка сповіщень
• Адміністративна панель для управління (React/Vue)
• Навантажувальне тестування (до 1000 паралельних, фактично витримуємо 5000)
• Документація API та навчання персоналу

Терміни реалізації

Базова система з одним типом ресурсу, без оплати — 8–10 робочих днів. Розширена версія з декількома типами, CMS, оплатою, SMS-сповіщеннями, політиками скасування — 14–18 робочих днів.

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

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

PostgreSQL documentation: https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-EXCLUSION