Arquitectura de Fooodo
Cómo está construido Fooodo — la división en dos servicios de la aplicación de menú y el servicio de pagos, el modelo de multi-tenancy de empresa/restaurante/mesa, el contrato de conector agnóstico de POS, y dónde se sitúa UVS.
Fooodo funciona como dos servicios cooperantes más un POS externo, al que se accede mediante un contrato de conector agnóstico de POS. Esta página es el mapa del sistema: cómo se conectan las piezas, por qué están separadas y cómo funciona el multi-tenancy.
Los dos servicios
- Aplicación de menú. Flujo orientado al cliente (QR → explorar → pedir), el panel de administración del operador y todo el tráfico del conector POS.
- Servicio de pagos. Servicio independiente detrás de una API autenticada por token. Gestiona la integración con Mollie, el enrutamiento de webhooks, el enrutamiento de donaciones y el enrutamiento de propinas. Dispone de su propio panel de administración interno.
- Conector POS. El POS que utilice el restaurante. Fooodo lo trata como el sistema de referencia para el menú y como la fuente de verdad de la cocina para los pedidos. R-Keeper es el conector de referencia activo hoy en día; otros conectores POS se definen por cliente — el propio contrato de conector es agnóstico de POS.
Los dos servicios de Fooodo se comunican a través de una API HTTP autenticada; no comparten base de datos, cola ni despliegue. Pueden desplegarse de forma independiente.
Por qué separar el servicio de pagos
Tres razones:
- El alcance de cumplimiento se mantiene reducido. Los datos de tarjeta solo tocan el servicio de pagos; la aplicación de menú recibe una URL de pago y un callback. El alcance PCI queda acotado a una única base de código.
- El servicio de pagos es reutilizable. Fue diseñado para dar servicio a múltiples superficies de Fooodo a lo largo del tiempo, no solo a la aplicación de menú actual. Los nuevos productos lo consumen sin necesidad de reimplementar la infraestructura de pagos.
- Aislamiento de fallos. Si Mollie sufre una interrupción regional, la aplicación de menú sigue funcionando; los pedidos se encolan en el estado «listos para pagar» y se reconcilian cuando el servicio de pagos se recupera.
Multi-tenancy
Cada registro de la aplicación de menú está delimitado mediante esta jerarquía:
- Companytenant boundary · brand · billing
- RestaurantPOS config · hours · default flow
- TableQR code · per-table flow override
- Orderitems · payments · tips · donations
- Company es el límite de tenant. Actualmente hay una empresa activa en producción (Čili Pizza), pero la separación de tenants se aplica en todas partes — añadir una segunda cadena no requiere un despliegue independiente.
- Los administradores de restaurante solo pueden gestionar su propio restaurante — el sistema de roles lo impone a nivel de política.
- Cada código QR se resuelve en una mesa concreta de un restaurante concreto. No existe un código genérico de «escanear para pedir»; Fooodo siempre sabe para qué asiento es un pedido. Esto es lo que hace posible Pay-Later, la división de cuenta en mesa y los análisis por asiento.
Dónde se sitúa UVS
UVS es el núcleo de pedidos y operaciones dentro de la aplicación de menú — el flujo de eventos central que registra todo lo que escribe la plataforma (pedidos, pagos, estado de mesas, tickets de cocina) antes de propagarlo a los consumidores (el conector POS activo, el servicio de pagos, módulos futuros).
Para los integradores esto tiene una implicación concreta: los módulos no se comunican directamente entre sí, y el contrato es agnóstico de POS. Un conector para un nuevo POS no toca el flujo de cocina ni el servicio de pagos — habla el contrato UVS y hereda pagos, multi-tenancy e informes de forma automática. R-Keeper es una implementación de ese contrato; el contrato en sí es el sistema. El contrato está documentado en el repositorio de integración, que los socios reciben durante el proceso de incorporación.
El stack de un vistazo
| Componente | Descripción |
|---|---|
| Aplicación de menú | Backend PHP, frontend React, PostgreSQL, cola de trabajos respaldada por Redis |
| Servicio de pagos | Servicio PHP independiente con su propia base de datos y panel de administración |
| Proveedor de pagos | Mollie (tarjeta, Apple Pay, Google Pay) |
| Conector POS | R-Keeper (activo); otros conectores POS definidos por cliente |
| Sitio de marketing | Next.js + next-intl + Fumadocs (este sitio) |
Las versiones específicas de los frameworks se omiten intencionadamente de esta superficie pública — los socios que desarrollan conectores POS reciben el anclaje de versiones durante el proceso de incorporación, junto con el repositorio de integración.
Qué reside en cada lugar
- Gestión de menú, pedidos, mesas, flujo orientado al cliente → aplicación de menú.
- Datos de tarjeta, reembolsos, métodos de pago, propinas, donaciones → servicio de pagos.
- Fuente de verdad del menú, tickets de cocina, informes → tu POS (R-Keeper hoy, otros conectores a medida que se publiquen).
- Contenido de marketing, documentación pública, asistente AI, servidor MCP → este sitio.
Si estás integrando con Fooodo, la superficie API que te interesa es la API externa de la aplicación de menú. El servicio de pagos es interno — la aplicación de menú actúa como proxy hacia él.
Primeros pasos con Fooodo
El proceso de incorporación paso a paso desde «acabamos de firmar» hasta los primeros pedidos en tu primer local — sincronización del menú, mesas con QR, el ensayo en seco y qué vigilar durante la primera semana.
Flujos de pedido — Pay-First vs Pay-Later
Cuándo usar Pay-First frente a Pay-Later, cómo se comporta cada uno de extremo a extremo, los estados de pedido que los operadores ven en el panel de administración y los trabajos en segundo plano que mantienen los pedidos sincronizados con el POS.