Архитектура Fooodo
Как устроен Fooodo — разделение на два сервиса (приложение меню и платёжный сервис), модель мультиарендности компания/ресторан/стол, POS-агностический контракт коннектора и место UVS в системе.
Fooodo работает как два взаимодействующих сервиса плюс внешний POS, доступный через POS-агностический контракт коннектора. Эта страница — карта системы: как части соединяются, почему они разделены и как работает мультиарендность.
Два сервиса
- Приложение меню. Клиентский поток (QR → просмотр → заказ), панель администратора оператора и весь трафик POS-коннектора.
- Платёжный сервис. Отдельный сервис за API с токен-аутентификацией. Владеет интеграцией Mollie, маршрутизацией вебхуков, маршрутизацией пожертвований и чаевых. Имеет собственный внутренний административный интерфейс.
- POS-коннектор. Любой POS, который использует ресторан. Fooodo рассматривает его как систему учёта меню и как источник истины для кухни по заказам. R-Keeper — действующий эталонный коннектор; другие POS-коннекторы разрабатываются под конкретного клиента, при этом сам контракт коннектора является POS-агностическим.
Два сервиса Fooodo взаимодействуют через аутентифицированный HTTP API; у них нет общей базы данных, общей очереди и общего развёртывания. Они могут разворачиваться независимо друг от друга.
Почему платёжный сервис выделен отдельно
Три причины:
- Область соответствия требованиям остаётся небольшой. Данные карт касаются только платёжного сервиса; приложение меню получает URL для оформления заказа и обратный вызов. Область PCI ограничена одной кодовой базой.
- Платёжный сервис можно использовать повторно. Он был спроектирован для обслуживания нескольких поверхностей Fooodo со временем, а не только текущего приложения меню. Новые продукты используют его без повторной реализации платёжной инфраструктуры.
- Изоляция сбоев. Если у Mollie происходит региональный сбой, приложение меню продолжает работать; заказы накапливаются в состоянии «готов к оплате» и согласуются после восстановления платёжного сервиса.
Мультиарендность
Каждая запись в приложении меню привязана к следующей иерархии:
- Companytenant boundary · brand · billing
- RestaurantPOS config · hours · default flow
- TableQR code · per-table flow override
- Orderitems · payments · tips · donations
- Компания — граница арендатора. В настоящее время в продакшене одна активная компания (Čili Pizza), однако разделение арендаторов применяется повсеместно — добавление второй сети не требует отдельного развёртывания.
- Администраторы ресторана могут управлять только своим рестораном — система ролей обеспечивает это на уровне политик.
- Каждый QR-код ведёт к конкретному столу в конкретном ресторане. Общего кода «отсканируй и закажи» не существует; Fooodo всегда знает, для какого места предназначен заказ. Именно это делает возможными оплату после еды, разделение счёта у стола и аналитику на уровне места.
Место UVS в системе
UVS — это ядро заказов и операций внутри приложения меню: центральный поток событий, который фиксирует всё, что записывает платформа (заказы, платежи, состояние столов, кухонные тикеты), прежде чем распространить данные потребителям (активному POS-коннектору, платёжному сервису, будущим модулям).
Для интеграторов это имеет конкретное практическое значение: модули не общаются друг с другом напрямую, а контракт является POS-агностическим. Коннектор для нового POS не затрагивает кухонный поток или платёжный сервис — он говорит на языке контракта UVS и автоматически получает платежи, мультиарендность и отчётность. R-Keeper — одна из реализаций этого контракта; сам контракт и есть система. Контракт задокументирован в репозитории интеграции, который партнёры получают в процессе подключения.
Стек в кратком изложении
| Компонент | Описание |
|---|---|
| Приложение меню | PHP-бэкенд, React-фронтенд, PostgreSQL, очередь задач на основе Redis |
| Платёжный сервис | Независимый PHP-сервис с собственной базой данных и административным интерфейсом |
| Платёжный провайдер | Mollie (карты, Apple Pay, Google Pay) |
| POS-коннектор | R-Keeper (действующий); другие POS-коннекторы разрабатываются под конкретного клиента |
| Маркетинговый сайт | Next.js + next-intl + Fumadocs (этот сайт) |
Конкретные версии фреймворков намеренно не указываются в этой публичной документации — партнёры, создающие POS-коннекторы, получают информацию о закреплённых версиях в процессе подключения вместе с репозиторием интеграции.
Что где находится
- Управление меню, заказы, столы, клиентский поток → приложение меню.
- Данные карт, возвраты, способы оплаты, чаевые, пожертвования → платёжный сервис.
- Источник истины меню, кухонные тикеты, отчёты → ваш POS (сегодня R-Keeper, другие коннекторы по мере выпуска).
- Маркетинговые материалы, публичная документация, AI-ассистент, MCP-сервер → этот сайт.
Если вы интегрируетесь с Fooodo, API-поверхность, которая вас касается, — это внешний API приложения меню. Платёжный сервис является внутренним — приложение меню проксирует запросы к нему.
Начало работы с Fooodo
Практический путь онбординга от «мы только что подписали» до живых заказов в вашем первом заведении — синхронизация меню, QR-столики, пробный запуск и за чем следить в первую неделю.
Потоки заказов — Pay-First и Pay-Later
Когда использовать Pay-First и Pay-Later, как каждый из них работает от начала до конца, какие статусы заказов видят операторы в панели администратора и какие фоновые задания поддерживают синхронизацию заказов с POS.