Платформа бронирования соединяет провайдеров услуг — мастеров, специалистов, арендодателей — с клиентами через удобную систему онлайн-записи. Типичная ситуация: мастер салона красоты ведёт запись в Excel, клиенты звонят, возникают двойные бронирования и потерянные заказы. Мы разрабатываем систему, которая автоматизирует расписание, принимает оплату онлайн и синхронизируется с календарём. Наш опыт более 5 лет: от простых решений для одиночных специалистов до маркетплейсов с тысячами провайдеров. Ключевые компоненты: управление расписанием, слоты времени, предоплата и отмены, уведомления. В этой статье разберём техническую реализацию на примере нашего стека (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 documentation) или уникальный индекс с 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%, что позволяет сэкономить до 150 000 рублей в год. Комиссия платформы составляет 15%.
Сроки
MVP (профиль провайдера, расписание, бронирование, оплата, уведомления): от 2 до 3 месяцев. Полнофункциональный маркетплейс с аналитикой, мобильным приложением и множественными провайдерами: от 4 до 6 месяцев. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальное решение и сроки. Закажите консультацию, чтобы обсудить детали.