Розробка мобільного додатку для бронювання: вирішуємо конфлікти та відміни
Конфлікти бронювання та відміни в останню хвилину — часта проблема сервісів. Ми пропонуємо розробку мобільного додатку для бронювання під ключ за 4–6 тижнів від $3000. За 5+ років реалізували 30+ проєктів для салонів краси, медичних центрів та фітнес-клубів. Наші додатки зменшують no-show на 20% — у 2 рази краще за середній ринковий показник (10%). Економія для бізнесу — до $5000 на місяць завдяки депозитам та push-нагадуванням.
Як уникнути race condition при бронюванні?
Race condition (Wikipedia) — класична проблема паралельного доступу, яку ми вирішуємо оптимістичним блокуванням. Двоє клієнтів бачать вільний слот о 14:00 в одного майстра і натискають «Записатися». Без правильної синхронізації обидва отримають підтвердження. Ми використовуємо оптимістичне блокування: запис із версією слота в БД (поле version) або SELECT FOR UPDATE на сервері. Оптимістичне блокування знижує конфлікти на 95% порівняно з песимістичним. Мобільний клієнт обробляє 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 із вкладеним RecyclerView. На Flutter — TableCalendar або кастомне рішення з підтримкою перетягування (drag & drop) для майстра.
Слоти розраховуються з урахуванням: робочих годин майстра, тривалості послуги, уже зайнятих слотів, перерв між записами (наприклад, 15 хвилин на підготовку). Уся логіка — на сервері, клієнт отримує готову видачу. Для мультимайстер-сценарію (клієнт обирає послугу, система призначає першого вільного) застосовуємо round-robin або пріоритет за рейтингом.
Push-нагадування та відміна з повідомлення
Нагадування за 24 та 2 години — scheduled job на сервері (Sidekiq/Celery). Клієнт не керує таймінгами, тільки приймає push. На iOS — UNNotificationAction для відміни запису прямо з повідомлення. На Android — кнопка дії в FCM. Користувач може відмінити, не відкриваючи додаток — зручність, що знижує навантаження на підтримку на 30%.
Оплата: три сценарії та холдування
- Без передоплати — базовий запис.
- Часткова передоплата (депозит) — 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% запитів обробляються за <200 ms.
- UI-тести (Detox/XCUITest) — прохід за ключовими сценаріями (запис, відміна, оплата).
Типові помилки на старті:
- Немає розрахунку перерв між слотами — клієнти скаржаться на накладки.
- Синхронізація тільки через polling — затримки до 30 секунд, втрата броней.
- Ігнорування timezone майстра — клієнти з інших часових поясів записуються не туди.
Гарантуємо, що додаток стабільний під високим навантаженням — досвід верифікації на бойових проектах 30+ клієнтів. Оцініть ваш проект — зв'яжіться з нами для консультації. Пропонуємо демонстрацію та попередній roadmap безкоштовно. Замовте розробку додатку для бронювання під ключ уже сьогодні!