Платформа бронювання з'єднує провайдерів послуг — майстрів, спеціалістів, орендодавців — із клієнтами через зручну систему онлайн-запису. Типова ситуація: майстер салону краси веде запис в Excel, клієнти телефонують, виникають подвійні бронювання та втрачені замовлення. Ми розробляємо систему, яка автоматизує розклад, приймає оплату онлайн і синхронізується з календарем. Наш досвід — від простих рішень для поодиноких спеціалістів до маркетплейсів із тисячами провайдерів. Ключові компоненти: управління розкладом, слоти часу, передоплата та скасування, сповіщення. У цій статті розберемо технічну реалізацію на прикладі нашого стека (PostgreSQL, Laravel, React) і типові складнощі, такі як race condition при бронюванні.
Основні можливості платформи бронювання
Як модель розкладу запобігає конфліктам?
Розклад провайдера визначає доступні слоти для бронювання. Основа — дві таблиці: schedules для регулярного графіка та schedule_exceptions для винятків (відпустка, вихідні, термінові справи). Алгоритм генерації вільних слотів виглядає так: беремо робочі години дня з schedules → віднімаємо вже заброньовані в bookings → віднімаємо буферний час між записами → повертаємо вільні інтервали.
-- Регулярний робочий графік CREATE TABLE schedules ( provider_id, day_of_week INT (0-6), start_time TIME, end_time TIME ); -- Винятки (вихідні, відпустка) CREATE TABLE schedule_exceptions ( provider_id, exception_date DATE, is_available BOOLEAN, -- false = недоступний custom_start TIME, custom_end TIME -- інший розклад у цей день ); -- Заброньовані слоти CREATE TABLE bookings ( id, provider_id, client_id, service_id, start_at TIMESTAMPTZ, end_at TIMESTAMPTZ, status ENUM('pending', 'confirmed', 'cancelled', 'completed') ); Як уникнути double booking?
Double booking — класична проблема для систем бронювання. Уявіть: два клієнти одночасно натискають «Забронювати» на один слот. У нашій практиці race condition — найчастіша причина втрачених замовлень. Рішення — використовувати PostgreSQL advisory lock (див. документацію PostgreSQL) або унікальний індекс з INSERT ... ON CONFLICT.
SELECT pg_advisory_xact_lock(provider_id, unix_timestamp_of_slot); -- перевіряємо зайнятість -- створюємо бронь -- lock знімається автоматично по завершенні транзакції Або більш елегантний варіант: унікальний індекс по (provider_id, start_at) і вставка через INSERT ON CONFLICT DO NOTHING. При конкурентній вставці друга транзакція не запише дубль і поверне помилку — її потрібно обробити на рівні додатка та повідомити клієнта. Ми використовуємо перший підхід з advisory lock, оскільки він не вимагає дозволу на унікальність для всіх станів броні (наприклад, скасовані броні не повинні блокувати). Advisory lock у 2 рази швидший при високих навантаженнях (понад 100 бронювань за секунду).
Управління послугами провайдера
Кожен провайдер налаштовує свої послуги: назва, опис, тривалість, ціна, буферний час після сесії, вимоги до клієнтів. Буфер — важлива деталь: якщо запис триває годину, а буфер 15 хвилин, наступний слот почнеться лише через 1:15. Це запобігає запізненням і дає час на підготовку.
Політики скасування бронювання
Стандартні політики скасування можна порівняти в таблиці:
| Політика | Термін скасування для повного повернення | Термін скасування для часткового повернення | Повернення при запізненні |
|---|---|---|---|
| Flexible | за 24 години | – | 100% |
| Moderate | за 5 днів | за 24 години (50%) | 50% |
| Strict | за 14 днів (50%) | пізніше — 0% | 0% |
Провайдер обирає одну з політик. При скасуванні клієнтом автоматично розраховується сума повернення через Stripe Refund. При скасуванні провайдером — повне повернення клієнту завжди.
Як інтегрувати Google Calendar? Покрокова інструкція
- Авторизація OAuth2: провайдер авторизує доступ до свого календаря через стандартний OAuth2 flow.
- Синхронізація подій: нові бронювання автоматично створюють події в Google Calendar через Google Calendar API. Події блокують слоти на платформі.
- Зворотна синхронізація: блокуючі події з календаря провайдера (наприклад, особисті зустрічі) позначають його як недоступного в цей час.
- Обробка змін: при скасуванні броні відповідна подія видаляється або позначається як підтверджена.
Нагадування та сповіщення
Автоматичні нагадування знижують кількість неявок. Ми налаштовуємо:
- Підтвердження бронювання (миттєво)
- Нагадування за 24 години (email + SMS через Twilio)
- Нагадування за 1 годину (push-сповіщення в мобільному додатку)
- Прохання залишити відгук через 2 години після візиту
Порівняння підходів до запобігання double booking
| Метод | Продуктивність | Надійність | Складність |
|---|---|---|---|
| Advisory lock | Висока (2x швидше) | 100% гарантія | Середня |
| Унікальний індекс | Середня | 99.9% (можливі колізії) | Низька |
Вибір залежить від навантаження. Для високонавантажених платформ (100+ запитів/с) ми рекомендуємо advisory lock.
Що входить у роботу
При замовленні розробки платформи бронювання ми надаємо:
- Архітектурну схему та опис API
- Вихідний код у репозиторії (Git)
- Міграції бази даних для всіх середовищ
- Інтеграцію з платіжним шлюзом (Stripe, ЮKassa)
- Інтеграцію з Google Calendar / Outlook
- Налаштування сповіщень (email, SMS, push)
- Документацію з розгортання та експлуатації
- Навчання адміністраторів і провайдерів
- Гарантійну підтримку 3 місяці після запуску
Чому обирають нас
Ми розробили понад 30 систем бронювання для різних сфер — від салонів краси до оренди приміщень. Наш досвід гарантує відсутність double booking, надійну обробку платежів і масштабування до тисяч паралельних запитів. Сертифіковані інженери з PostgreSQL та React. Середня економія часу адміністратора після впровадження — 40%. Комісія платформи становить 15%.
Терміни
MVP (профіль провайдера, розклад, бронювання, оплата, сповіщення): від 2 до 3 місяців. Повнофункціональний маркетплейс з аналітикою, мобільним додатком і множинними провайдерами: від 4 до 6 місяців. Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення та терміни. Замовте консультацію, щоб обговорити деталі.