Разработка платформы для бронирования услуг

Платформа бронирования соединяет провайдеров услуг — мастеров, специалистов, арендодателей — с клиентами через удобную систему онлайн-записи. Типичная ситуация: мастер салона красоты ведёт запись в 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. Это предотвращает опоздания и даёт время на подготовку.

Политики отмены бронирования

Стандартные политики отмены можно сравнить в таблице:

Провайдер выбирает одну из политик. При отмене клиентом автоматически рассчитывается сумма возврата через Stripe Refund. При отмене провайдером — полный возврат клиенту всегда.

Как интегрировать Google Calendar? Пошаговая инструкция

1. Авторизация OAuth2: провайдер авторизует доступ к своему календарю через стандартный OAuth2 flow.
2. Синхронизация событий: новые бронирования автоматически создают события в Google Calendar через Google Calendar API. События блокируют слоты на платформе.
3. Обратная синхронизация: блокирующие события из календаря провайдера (например, личные встречи) отмечают его как недоступного в это время.
4. Обработка изменений: при отмене брони соответствующее событие удаляется или помечается как подтверждённое.

Напоминания и уведомления

Автоматические напоминания снижают количество неявок. Мы настраиваем:

• Подтверждение бронирования (мгновенно)
• Напоминание за 24 часа (email + SMS через Twilio)
• Напоминание за 1 час (push-уведомление в мобильном приложении)
• Просьба оставить отзыв через 2 часа после визита

Сравнение подходов к предотвращению double booking

Выбор зависит от нагрузки. Для высоконагруженных платформ (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 месяцев. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальное решение и сроки. Закажите консультацию, чтобы обсудить детали.

Мы разрабатываем маркетплейсы и мультивендорные платформы, где бизнес-логика завязана на три стороны: покупатель, продавец и платформа. Ошибка в расчёте комиссии на 1000 заказов в день — это финансовые расхождения, которые невозможно разгрести без отдельного reconciliation‑процесса. Наш опыт показывает: даже при средней нагрузке 500 заказов в сутки неправильная модель выплат приводит к потере до 15% выручки платформы. Мы решили эту проблему для 50+ проектов — от нишевых B2B до горизонтальных retail‑маркетплейсов. Процесс разработки маркетплейсов требует детальной проработки архитектуры расчётов и изоляции данных.

Как избежать расхождений в расчётах комиссий

Расчёт комиссии — самая критичная часть, где ошибки стоят денег. Правило первое: никогда не хранить комиссию как производную, всегда как факт. В момент создания заказа фиксируем: сумму заказа, процент комиссии платформы в этот момент, абсолютное значение комиссии, сумму к выплате продавцу. Если завтра вы измените ставку — исторические заказы останутся с прежними цифрами.

Модели комиссий (используем одну из или комбинируем):

Мы используем Stripe Connect как базовый стандарт. Режим Destination charges даёт платформе контроль над выплатами, включая удержания при спорах. Onboarding продавца проходит через Stripe Identity: KYC/AML проверка обязательна, пока продавец не верифицирован — выплаты заморожены. Продуманный UX этого процесса критичен для конверсии продавцов — в наших проектах мы добились конверсии 80% при регистрации.

Почему архитектура мультиарендности критична для изоляции данных

Первый шаг — выбор архитектуры мультиарендности. В shared‑schema режиме все продавцы в одних таблицах с vendor_id. Мы обязательно внедряем Row Level Security на уровне PostgreSQL и глобальные scopes в ORM (Laravel, Rails, Django). Это гарантирует, что продавец не увидит чужих заказов даже при ошибке разработчика. Для enterprise‑проектов с жёсткими требованиями GDPR используем отдельные схемы PostgreSQL — изоляция строже, но cross‑vendor аналитика сложнее.

Как реализовать складские остатки без race condition

Два покупателя одновременно добавляют последний товар в корзину. Кто его купит? Применяем optimistic locking при создании заказа:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарная операция — второй запрос вернёт 0 затронутых строк и получит ошибку «товар закончился». Типичная схема для высоконагруженных маркетплейсов.

Сравнение подходов к каталогу товаров

Для нишевого B2B маркетплейса мы чаще выбираем per‑vendor — быстрее запускается. Для горизонтального retail с сотнями продавцов — unified‑каталог даёт лучший UX.

Пайплайн модерации: автоматика и ручная верификация

Маркетплейс несёт ответственность за контент продавцов. Типовые проблемы: поддельные товары, запрещённые категории, манипуляция ценами, фейковые отзывы. Выстраиваем трёхуровневый пайплайн:

1. Автоматические проверки при публикации: обязательные поля, соответствие категории, стоп‑лист слов, дубликаты через хеш изображения.
2. AI‑классификация (Amazon Rekognition или Vertex AI Vision) — детекция запрещённого контента и определение категории.
3. Очередь ручной проверки для flagged товаров.

Статусная машина: draft → pending_review → active / rejected → suspended. Каждый переход — событие с причиной и модератором. Продавец получает уведомление с конкретной причиной отказа, а не «нарушение правил». Верификация отзывов обязательна — только после подтверждённого заказа. Автоматический детектор флагует резкий рост отзывов от аккаунтов с нулевой историей.

Поиск и рекомендации

Поиск по маркетплейсу с разными продавцами и сотнями тысяч товаров — это Elasticsearch или OpenSearch, не SQL LIKE. Векторный поиск для семантики, фасетная фильтрация через агрегации. Персонализированная лента на основе коллаборативной фильтрации. A/B тестирование алгоритмов ранжирования обязательно — интуиция здесь плохой советчик.

Процесс работы

Маркетплейс — итеративная разработка. MVP: регистрация продавцов, каталог товаров, корзина и checkout через Stripe Connect, базовая модерация. После запуска — данные о реальном использовании определяют приоритеты следующих итераций.

Типичный порядок:

• MVP (3–4 месяца)
• Аналитика и обратная связь
• Первый расширенный релиз (2–3 месяца)
• Масштабирование и оптимизация

Сроки и стоимость

• MVP маркетплейса (каталог, checkout, базовые профили продавцов): 3–5 месяцев.
• Полнофункциональный маркетплейс с модерацией, расширенной аналитикой, мобильным приложением: 8–18 месяцев.
• Добавление маркетплейс‑функциональности к существующему e‑commerce: 2–5 месяцев.

Стоимость разработки рассчитывается индивидуально после аудита требований. Ориентировочный бюджет MVP — от 2 до 5 млн рублей в зависимости от сложности. Точную оценку дадим на бесплатном предпроектном обследовании.

Что входит в работу

• Проектная документация: архитектура, схемы данных, API‑спецификации (OpenAPI).
• Доступы к репозиторию, CI/CD, документации по развёртыванию.
• Обучение команды заказчика работе с платформой.
• Техническая поддержка в течение первого месяца после запуска.

Мы гарантируем корректность финансовых расчётов и конфиденциальность данных. Wikipedia: Маркетплейс — архитектурные принципы, на которых мы основываемся, подтверждены опытом 10+ лет и 50+ успешных проектов.

Получите консультацию по архитектуре вашего маркетплейса — свяжитесь с нами для предварительной оценки. Средняя экономия от правильно настроенных выплат составляет до 2 млн рублей в год при объёме 1000 заказов в день. Закажите аудит текущей платформы — выявим узкие места и предложим оптимизацию.