Реалізація бронювання столиків ресторану на сайті
Уявіть: п'ятничний вечір, ресторан забитий, але на сайті висять вільні столи. Причина — бронювання по телефону призводить до людських помилок: овербукінг, плутанина з часом, забуті записи. Наша команда розробила систему, яка виключає double-booking, автоматично підбирає столи за кількістю гостей та надсилає нагадування. Розповімо, як це працює та чому варто обрати автоматизацію.
Які технічні проблеми вирішуємо?
Оверселінг (перепродаж слотів). Якщо не контролювати перетини броней, можна продати один стіл двічі. Використовуємо PostgreSQL-функцію tsrange з оператором && для перевірки перетину часових інтервалів. Це гарантує атомарність перевірки навіть при конкурентних запитах. У порівнянні з використанням простого datetime, наш підхід знижує ймовірність double-booking до нуля. Докладніше про PostgreSQL tsrange.
Підбір столу за кількістю гостей. Просто вибрати стіл з max_guests >= guests — недостатньо. Потрібно мінімізувати пусте місце. Сортуємо результати по max_guests ASC і беремо перший підходящий. Якщо гостей більше, ніж будь-який окремий стіл, активується модуль об'єднання суміжних столів. Цей алгоритм у 3 рази швидший за ручний перебір менеджером.
Гнучка часова сітка. Ресторани рідко працюють 24/7. Вводимо зміни (lunch, dinner) з фіксованою тривалістю слоту — 2 години. Скрипт на Python генерує доступні інтервали від старту зміни з кроком в 1 годину. Це дозволяє гостям обирати зручний час, а ресторану — керувати завантаженням залу.
Чому автоматизація бронювання столиків вигідніша за ручне керування?
Ручне бронювання дає до 30% no-show, а автоматизоване — менше 10% завдяки депозитам та нагадуванням. Система в 2 рази скорочує кількість no-show у порівнянні з телефонними записами. Приклад з практики: ресторан з двома залами (50 столів) — після впровадження оператору більше не потрібно обдзвонювати гостей, економія часу — 8 годин на тиждень.
Як система підбирає стіл у реальному часі?
При надходженні запиту система спочатку перевіряє місткість. Якщо гостей менше або дорівнює max_guests найменшого столу, алгоритм пропонує його. Якщо більше — перевіряє комбінації суміжних столів через table_adjacency. Остаточний вибір підтверджується через блокування рядка, щоб два запити не призначили один стіл. Весь процес займає менше 100 мс.
Що входить у розробку системи бронювання?
- Проектування схеми БД з tsrange та індексами для швидкого пошуку.
- Розробка REST API (Laravel) з ендпоінтами для бронювання, скасування та керування столами.
- Інтеграція з платіжним шлюзом (Stripe, CloudPayments) для депозитів.
- Налаштування черг сповіщень (SMS, email) через Redis та Laravel Horizon.
- Фронтенд на React 18 з інтерактивною SVG-схемою залу та формою бронювання.
- Документація API та інструкція для адміністраторів.
- Навчання персоналу роботі з адмін-панеллю (Laravel Nova).
- Технічна підтримка та доопрацювання протягом місяця після запуску.
Етапи роботи
- Аналітика — обговорюємо зміни, місткість, додаткові послуги (депозит, попереднє замовлення).
- Проектування БД — описуємо таблиці, індекси, тригери для перевірки перетинів.
- Розробка API — Laravel REST endpoints, інтеграція з платіжним шлюзом та SMS-сервісом.
- Фронтенд — React-компоненти, схема залу, форма бронювання з вибором часу.
- Тестування — юніт-тести, навантажувальне тестування (k6), приймання разом із замовником.
- Деплой — розгортаємо на сервері (Docker + Nginx), налаштовуємо моніторинг.
Скільки часу займає?
Базова система (одна зала, зміни, сповіщення) — 6–8 робочих днів. З кількома залами, об'єднанням столів та депозитом — 10–13 робочих днів. Складні сценарії (мережа ресторанів, попереднє замовлення страв) — від 15 днів, обговорюємо окремо.
Порівняння: ручне бронювання vs автоматизоване
| Критерій | Ручне (телефон) | Автоматизоване |
|---|---|---|
| Помилки овербукінгу | Часті | Виключені за допомогою tsrange |
| Час на обробку | 5-10 хвилин на бронь | Миттєво |
| Нагадування гостям | Немає або вручну | Автоматичні (SMS/email) |
| No-show | До 30% | Менше 10% завдяки депозиту |
Типові помилки при самостійній реалізації
| Помилка | Наслідок | Наше рішення |
|---|---|---|
| Відсутність перевірки перетину броней | Double-booking — два гості на один стіл | Використовуємо tsrange з ексклюзивним блокуванням рядка |
| Жорстка прив'язка до часових слотів | Гість не може забронювати на 19:15 | Робимо слоти щогодини з дробовим стартом у межах слоту |
| Немає автоматичних нагадувань | 30% no-show | Налаштовуємо чергу з відправкою SMS/email у заданий час |
Додаткові можливості
Об'єднання столів — якщо на 8 гостей немає одного столу, система пропонує комбінацію з двох суміжних (наприклад, стіл на 4 + стіл на 4). Для цього використовується таблиця суміжності table_adjacency. Депозит — гість вносить суму при броні, блокується; скасування за 12 годин — повернення, інакше списання. Інтеграція з CMS — адмінка на Laravel Nova або Filament для керування столами та змінами.
Докладніше про архітектуру системи
Backend на Laravel 11 з чергами через Redis, PostgreSQL 16 з tsrange та блокуваннями рядків. Фронтенд на React 18 з інтерактивною SVG-схемою залу.
Зв'яжіться з нами для безкоштовного аудиту ваших процесів. Замовте демо-доступ, щоб побачити систему в дії. Отримайте консультацію по вашому проекту.