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

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

Політики скасування бронювання

Стандартні політики скасування можна порівняти в таблиці:

Провайдер обирає одну з політик. При скасуванні клієнтом автоматично розраховується сума повернення через 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%. Комісія платформи становить 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 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого 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 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

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

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.