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

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

Подвійне бронювання — головний біль будь-якого сервісу з розкладом. Помилка в цій зоні коштує не тільки нервів клієнтів, але й втраченої виручки — до 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