Конфликты бронирования, когда два клиента одновременно записываются на один слот, и отмены в последнюю минуту без предупреждения — частая головная боль для сервисов. Мы разрабатываем мобильные приложения для бронирования услуг, которые решают эти проблемы на уровне архитектуры. За 5+ лет мы реализовали 30+ проектов для салонов красоты, медицинских центров и фитнес-клубов — от кросс-платформенных решений до нативных приложений с Full HD-анимацией и real-time WebSocket. Каждое приложение проходит строгий аудит App Store Review Guidelines и Google Play Console policy, чтобы выйти в сторы без лишних задержек.
Как избежать race condition при бронировании?
Race condition — классическая головная боль. Двое клиентов видят свободный слот в 14:00 у одного мастера и нажимают «Записаться». Без правильной синхронизации оба получат подтверждение. Мы используем оптимистичную блокировку: запись с версией слота в БД (version-поле) или SELECT FOR UPDATE на сервере. Мобильный клиент обрабатывает 409 Conflict и показывает «Извините, слот только что занят. Выберите другое время» с актуальным списком свободных окон. Это снижает no-show на 20% и экономит бюджет клиента за счёт депозитов и push-напоминаний.
Почему real-time обновление расписания критически важно?
Если мастер работает в несколько каналов (сайт, Instagram, сторонние сервисы), слоты могут расходиться. WebSocket-соединение с сервером — лучший способ: при изменении расписания в любом канале все клиенты мгновенно видят новую картину. Сравните с периодическим опросом (polling) — WebSocket в 10 раз быстрее доставляет обновления и экономит трафик. На Flutter используем web_socket_channel, на React Native — react-native-websocket.
Как организовать расписание в приложении для бронирования?
Мобильный интерфейс расписания — горизонтальный скролл дат + вертикальный список слотов. На iOS — UICollectionViewCompositionalLayout, на Android — RecyclerView с nested RecyclerView. На Flutter — TableCalendar или кастомное решение с поддержкой перетаскивания (drag & drop) для мастера.
Слоты рассчитываются с учётом: рабочих часов мастера, длительности услуги, уже занятых слотов, перерывов между записями (например, 15 минут на подготовку). Вся логика — на сервере, клиент получает готовую выдачу. Для мультимастер-сценария (клиент выбирает услугу, система назначает первого свободного) применяем round-robin или приоритет по рейтингу.
Push-напоминания и отмена из уведомления
Напоминание за 24 и 2 часа — scheduled job на сервере (Sidekiq/Celery). Клиент не управляет таймингами, только принимает push. На iOS — UNNotificationAction для отмены записи прямо из уведомления. На Android — кнопка действия в FCM. Пользователь может отменить, не открывая приложение — удобство, снижающее нагрузку на поддержку.
Оплата: три сценария и холдирование
- Без предоплаты — базовая запись.
- Частичная предоплата (депозит) — 20% от суммы, удерживается против no-show. Возврат при отмене за X часов.
- Полная оплата онлайн — фиксация суммы сразу.
Продвинутый вариант — холдирование: PaymentIntent с capture_method: manual (Stripe). Деньги «замораживаются» на карте в момент записи, списываются после оказания услуги, возврат — refund. Требует подтверждения через confirmPaymentIntent.
| Сценарий | Описание | Пример использования |
|---|---|---|
| Без предоплаты | Запись без финансовых обязательств | Пробные визиты |
| Депозит | Холдирование части суммы, возврат при отмене | Салон красоты, медицинские центры |
| Полная оплата | Оплата всей услуги при бронировании | Фитнес-тренировки, консультации |
Что входит в работу
- Анализ бизнес-процессов и проектирование архитектуры (C4 models).
- Разработка серверной части (REST/GraphQL API) и мобильного клиента.
- Интеграция платёжного шлюза (Stripe, Tinkoff, ЮKassa) и push-сервисов (FCM/APNs).
- Настройка WebSocket для real-time расписания.
- Тестирование: unit, integration, нагрузочное (имитация 1000 одновременных броней).
- Деплой в App Store / Google Play с соблюдением правил стора.
- Документация для разработчиков и инструкции для конечных пользователей.
- Поддержка 1 месяц после запуска.
| Этап | Срок (ориентир) |
|---|---|
| Аналитика и прототип | 1 неделя |
| Разработка MVP | 4–6 недель |
| Полноценная платформа | 2–3 месяца |
| Тестирование и деплой | 1–2 недели |
Как мы тестируем бронирование от юнит-тестов до нагрузочного?
- Юнит-тесты — покрываем core-логику (расчёт слотов, приоритизация мастеров).
- Интеграционные тесты — симуляция одновременной записи двух клиентов, проверка блокировок.
- Нагрузочное тестирование — 1000 concurrent запросов через Gatling или k6, убеждаемся, что 99% запросов обрабатываются за <200ms.
- UI-тесты (Detox/XCUITest) — проход по ключевым сценариям (запись, отмена, оплата).
Типичные ошибки на старте:
- Нет расчёта перерывов между слотами — клиенты жалуются на накладки.
- Синхронизация только через polling — задержки до 30 секунд, потеря броней.
- Игнорирование timezone мастера — клиенты из других часовых поясов записываются не туда.
Гарантируем, что приложение стабильно под высокой нагрузкой — опыт верификации на боевых проектах 30+ клиентов. Инвестиции в MVP обсуждаются индивидуально, сроки — от 4 недель. Свяжитесь с нами для консультации и получите предварительный roadmap. Закажите демонстрацию под ваш проект.
Race condition — классическая проблема параллельного доступа, которую мы решаем оптимистичной блокировкой.