Бронирование стола в ресторане — задача с нетривиальными техническими узлами: временные слоты, вместимость, депозиты и правила отмены. Многие проекты спотыкаются на race condition при одновременных бронях. Решение — серверная валидация с блокировками PostgreSQL SELECT ... FOR UPDATE. Наш опыт — более 10 реализованных проектов для ресторанов разного формата, от небольших кафе до сетевых заведений с сотнями столов. Среднее время оборота стола — 90 минут, депозит часто устанавливается в размере стоимости одного блюда. Чтобы исключить коллизии, мы используем транзакции и очереди Laravel.
Почему серверная валидация критична?
Главная ошибка при проектировании — хранить бронирования просто как строки в таблице с datetime. Это работает до первого «стол на 4 занят частично» или «гость хочет столик у окна или у бара». Проверка доступности должна выполняться на сервере: при выборе даты и числа гостей запрос к бэкенду возвращает доступные временные слоты. Сервер проверяет отсутствие пересечений по времени (с учётом avg_turnover_time, например 90 минут) и наличие столов нужной вместимости. Использование SELECT ... FOR UPDATE гарантирует, что параллельные запросы не создадут две брони на один стол. Клиентская валидация здесь опасна — race condition неизбежен.
Модель данных для резервирования
Правильная модель: Table (номер, вместимость, зона, особенности) → Reservation (table_id, datetime_start, datetime_end, guests_count, status, deposit_status) → Guest (профиль, история визитов, предпочтения). Таблица Reservation содержит статус: pending, confirmed, cancelled. Deposit_status — held, captured, refunded. Для проверки доступности используется запрос, который ищет пересечения по времени для конкретного стола.
Как устроены депозиты?
Ресторан хочет застраховаться от no-show (до 15% гостей не приходят). Депозит при бронировании через ЮKassa — холдирование суммы на карте (метод hold), списание при подтверждении визита или возврат при отмене. Холдирование — это не списание, а блокировка средств, как указано в документации ЮKassa. Политика отмены: бесплатно за 24 часа, 50% депозита за 4 часа, 100% при no-show. Логика реализована на бэкенде с помощью Laravel scheduled jobs — они проверяют бронирования за час до дедлайнов и запускают холдирование или возврат.
Пример расчёта времени оборота стола
Если среднее время пребывания гостя — 1.5 часа, то для 20 столов при загрузке 80% необходимо пропускную способность 20×0.8×24/1.5 ≈ 256 гостей в день. На основе этих данных настраиваются временные слоты.Уведомления
Push через FCM: подтверждение брони сразу, напоминание за 24 часа и за 2 часа. Если ресторан принимает бронирование вручную — пуш «Ваш столик подтверждён» после одобрения менеджером. SMS через СМСЦентр как резервный канал — не все пользователи разрешают push.
Административная панель
Менеджер ресторана видит план зала на сегодня с визуализацией занятых/свободных столов, может изменить бронирование, добавить заметки («аллергия на орехи», «день рождения»), отметить no-show. Веб-интерфейс на React — удобнее для десктопа в зале.
Таблица: сравнение подходов к проверке доступности
| Критерий | Клиентская валидация | Серверная валидация |
|---|---|---|
| Скорость ответа | Мгновенная | Зависит от сети |
| Race condition | Возможны коллизии | Исключены блокировками |
| Сложность реализации | Низкая | Средняя |
| Рекомендация | Только для демо | Для продакшена |
Таблица: примерное распределение времени на этапы
| Этап | Длительность (недели) |
|---|---|
| Аналитика и прототип | 2-3 |
| Дизайн UI/UX | 2-3 |
| Разработка клиента | 8-10 |
| Разработка бэкенда | 6-8 |
| Интеграция и тестирование | 3-4 |
| Деплой и документация | 1-2 |
Что входит в работу
Мы предоставляем полный цикл разработки:
- Дизайн UI/UX (Figma макеты)
- Разработка клиентского приложения на Flutter 3.x
- Разработка бэкенда на Laravel + PostgreSQL
- Административная панель на React
- Интеграция с ЮKassa, FCM, SMS-центром
- Тестирование и отладка
- Деплой в App Store и Google Play
- Техническая документация
- Поддержка 2 недели после запуска
Приложение включает бронирование с выбором стола по схеме зала, депозиты, push- и SMS-уведомления, админ-панель для управления бронями и интеграцию с CRM ресторана. Все функции реализуются с учётом серверной валидации и защиты от race condition.
Сроки и стоимость
Приложение с бронированием, депозитами, уведомлениями и административной панелью — от 12 до 16 недель. Стоимость рассчитывается индивидуально после анализа требований. Свяжитесь с нами для обсуждения вашего проекта — получите консультацию по сценарию. Закажите демо-версию, чтобы оценить функционал в действии.