Архитектура 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 всегда знает, для какого места предназначен заказ. Именно это делает возможными оплату после заказа (Pay-Later), разделение счёта у стола и аналитику на уровне места.
Место UVS в системе
UVS — это ядро заказов и операций внутри приложения меню: центральный поток событий, который фиксирует всё, что записывает платформа (заказы, платежи, состояние столов, кухонные тикеты), прежде чем распространить данные потребителям (активному POS-коннектору, платёжному сервису, будущим модулям).
Для интеграторов это имеет конкретное практическое значение: модули не взаимодействуют друг с другом напрямую, а контракт является POS-агностическим. Коннектор для новой POS-системы не затрагивает кухонный поток или платёжный сервис — он работает по контракту UVS и автоматически получает платежи, мультитенантность и отчётность. R-Keeper — одна из реализаций этого контракта; сам контракт и есть система. Контракт задокументирован в репозитории интеграции, который партнёры получают в процессе подключения.
Стек в кратком изложении
| Компонент | Описание |
|---|---|
| Приложение меню | PHP-бэкенд, React-фронтенд, PostgreSQL, очередь задач на основе Redis |
| Платёжный сервис | Независимый PHP-сервис с собственной базой данных и административным интерфейсом |
| Платёжный провайдер | Mollie (Card, Apple Pay, Google Pay, Trustly) плюс наличные для авторизованных гостей |
| 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.