Versión
v1.0 del blueprint
Documento de arquitectura
Backend transaccional para POS multiempresa
Diseño base de un backend en Go orientado a restaurantes con múltiples empresas y múltiples sucursales dentro de un mismo cliente, con foco en consistencia operativa, trazabilidad y control transaccional.
Estado
Base arquitectónica definida para implementación backend-first.
Fecha
07 abril 2026
Modelo de aislamiento
1 cliente = 1 DB. Dentro de cada base, la operación se organiza por organization_id y business_unit_id.
Fuente de verdad
PostgreSQL concentra integridad, ledgers append-only, idempotencia, outbox y validaciones críticas.
Estrategia de validación
Primero se valida el backend por API y flujos reales de negocio; la interfaz se monta después sobre contratos estables.
Resumen
El sistema está pensado como un núcleo operativo para grupos restauranteros que necesitan controlar ventas, caja, inventario, compras y cuentas por pagar sin depender de procesos manuales o integraciones parciales. La lógica crítica no se delega al frontend ni a herramientas auxiliares: vive en el backend y en la base de datos.
La arquitectura elegida prioriza confiabilidad por encima de rapidez superficial de prototipado. Por eso se adopta un enfoque backend-first, con Go como lenguaje principal y PostgreSQL como motor de integridad del dominio.
Alcance de v1
Núcleo operacional
- Identidad y permisos
- Catálogo comercial y configuración POS
- Sesiones de caja y operación POS
- Órdenes, modifiers, descuentos y producción
- Pagos, reversas, propinas y crédito cliente
Circuito de abastecimiento
- Inventario y costo promedio
- Compras y recepciones
- Cuentas por pagar
- Sync e idempotencia base
- Reporting operativo básico
Fuera del foco inicial
- Frontend final de operación o backoffice.
- Control-plane completo de provisioning y operación global.
- Analítica avanzada o BI.
- Pagos electrónicos offline.
- Automatizaciones fiscales o integraciones no modeladas aún.
La primera validación del producto se basa en demostrar que los flujos reales de negocio quedan correctamente cerrados por API: orden → cobro → inventario, y compra → recepción → inventario → cuentas por pagar.
Decisiones estructurales
| Decisión | Razón |
|---|---|
| Go como backend | Control explícito de transacciones, buen ajuste para workers y baja complejidad operativa por servicio. |
| PostgreSQL como núcleo | El schema ya modela integridad, ledgers, outbox e idempotencia con un enfoque DB-first. |
| DB por cliente | Aislamiento real de datos y reducción del riesgo cross-client. |
Sin license_id operativo | El licenciamiento se resuelve fuera del dominio transaccional. |
| Ledgers append-only | Pagos e inventario deben corregirse con movimientos compensatorios, no con updates destructivos. |