Plataforma POS Multi-Tenant: Build, Operate, Transfer

Envadel fue contratado bajo un contrato Build-Operate-Transfer completo de 12 meses con tres fases definidas: Build (meses 1-4) — arquitectura, desarrollo y despliegue de la nueva plataforma POS multi-tenant; Operate (meses 5-8) — operación de la plataforma en producción, migración incremental de ubicaciones, estabilización y optimización; Transfer (meses 9-12) — apoyo en contratación, formación, documentación y traspaso gradual al nuevo equipo interno del cliente.

El enfoque priorizó la migración incremental: la nueva plataforma se desplegó junto al sistema legacy, con ubicaciones migradas en oleadas de 20-30 restaurantes. Cada oleada incluía una fase piloto (2-3 ubicaciones durante 1 semana), validación y luego migración masiva. Una capa de sincronización de datos en tiempo real aseguraba que el reporting corporativo fuera preciso independientemente de qué plataforma estuviera ejecutando cada ubicación individual.

Cada fase BOT tenía criterios de salida explícitos y gates de aprobación ejecutiva. La fase Build requería pasar tests de aceptación para todos los módulos core (pedidos, pagos, inventario, reporting, multi-tenancy). La fase Operate requería más de 200 ubicaciones migradas con éxito con un uptime del 99,5%+. La fase Transfer requería arquitectura documentada, runbooks, procedimientos de guardia y un nuevo equipo interno operando de forma independiente durante 30 días.

La nueva plataforma se construyó sobre Node.js con TypeScript para los servicios backend y React con TypeScript para el frontend (interfaz del terminal POS, pantalla de cocina, dashboard de gestión). PostgreSQL fue la base de datos principal, usando políticas de row-level security (RLS) y esquemas con alcance de tenant para aplicar el aislamiento de datos a nivel de base de datos — asegurando que ninguna consulta de un tenant pudiera acceder a los datos de otro, incluso en caso de bugs a nivel de aplicación.

Redis sirvió múltiples propósitos: gestión de sesiones para terminales POS, sincronización de cola de pedidos en tiempo real entre los sistemas POS y pantalla de cocina, y caché de configuraciones de menú y reglas de precios. Una arquitectura event-driven usando RabbitMQ gestionaba los flujos asíncronos: confirmaciones de procesamiento de pagos, actualizaciones de inventario y agregación de reporting entre ubicaciones. Cada ubicación mantenía un buffer local de eventos para resiliencia offline — si la conectividad se interrumpía, el POS continuaba operando y sincronizaba al reconectarse.

La infraestructura se ejecutó en Azure (proveedor cloud existente del cliente), completamente codificada con Terraform. AKS (Azure Kubernetes Service) alojaba la capa de aplicación con auto-scaling configurado por servicio. Azure Database for PostgreSQL proporcionó el tier de base de datos gestionada con backups automatizados, recuperación point-in-time y réplicas de lectura para la carga de reporting. Azure CDN sirvió el frontend React, y Azure Front Door proporcionó balanceo de carga global y protección WAF.

Las herramientas de migración se construyeron a medida: un pipeline ETL personalizado extraía datos de la base de datos MySQL legacy, los transformaba al nuevo esquema multi-tenant (añadiendo tenant IDs, normalizando estructuras de menú, mapeando referencias de pago legacy) y los cargaba en PostgreSQL. La migración de cada ubicación era atómica y reversible — si alguna verificación de validación fallaba, la ubicación se revertía automáticamente al sistema legacy sin pérdida de datos.

La fase Build (meses 1-4) siguió sprints de 2 semanas con sesiones de demo cada sprint al CTO y director de operaciones del cliente. El primer despliegue en producción (piloto con 3 ubicaciones) ocurrió al final del mes 3, proporcionando feedback temprano del mundo real que dio forma al trabajo de build restante. Decisiones clave — como añadir capacidades de resiliencia offline — surgieron de este feedback del piloto.

La fase Operate (meses 5-8) cambió a una pista dual: desarrollo continuo de funcionalidades en sprints más un workstream dedicado de migración. Las ubicaciones se migraron en oleadas de 20-30, con cada oleada tomando aproximadamente 2 semanas (piloto → validar → migración masiva). Se estableció un war room durante los fines de semana de migración con equipos de operaciones de Envadel y del cliente presentes para resolución de incidencias en tiempo real.

La fase Transfer (meses 9-12) se estructuró en torno a la transferencia de conocimiento y construcción del equipo. El equipo de Envadel realizó más de 40 horas de sesiones de formación grabadas cubriendo decisiones de arquitectura, runbooks operativos, procedimientos de despliegue y guías de troubleshooting. El cliente contrató a 4 nuevos ingenieros durante esta fase, cada uno emparejado con un ingeniero de Envadel para transferencia de conocimiento práctica.

El reporting ejecutivo siguió la misma cadencia durante todo el proceso: estado semanal, resumen ejecutivo mensual y revisiones de phase-gate en cada transición (Build→Operate, Operate→Transfer). La Transfer se completó formalmente cuando el equipo del cliente operó de forma independiente durante 30 días consecutivos con métricas que cumplían los umbrales de SLA acordados.