Documento consultivo N° 03011226
Emitido el 01 de enero de 1970
MrJoy · Equipo de Operaciones & Tecnología
Autotótems MrJoy · Análisis comparativo de arquitecturas de backend
Este documento es una lectura consultiva sobre el proyecto de autotótems ya en proceso. El objetivo no es cotizar hardware ni software nuevo, sino ordenar los tres escenarios de backend posibles, explicar cómo funciona cada uno y dar una recomendación técnica antes de tomar la decisión final. Al pie encontrarán únicamente el esfuerzo estimado —en horas— que implica llevar el proyecto al escenario recomendado.
SITUACIÓN ACTUAL: el proyecto está contratado sobre el Caso 1. dado que el cliente quería hacerlo primero sobre un solo totem y en una sola tienda; además se siguió el lineamiento indicado por TI, que era adecuado para es contexto. Sin embargo, Mr Joy ha evolucionado su ambición y ahora se está implementado el sistema en varias tiendas a la vez. Por eso, están evaluando migrar al Caso 2 (servidor local por sucursal), pero dado el cambio, Pulpa recomienda saltar directamente al Caso 3 (nube central con modo offline), por las razones que se detallan en las secciones siguientes.
Escenarios
Los tres casos, explicados en detalle
CASO 1
Base de datos local aislada por tótem
Arquitectura contratada originalmente
Diagrama de flujo · equipo técnico
Cómo funciona el flujo
- 01Cada autotótem opera como una caja cerrada e independiente del resto.
- 02El frontend Angular envía la orden al backend TypeScript instalado en el propio equipo.
- 03El servicio puente Python autoriza el cobro contra el POS físico conectado al tótem.
- 04La venta se guarda en la base MySQL que vive dentro del mismo tótem.
A favor
- Autonomía total del equipo: no depende de red interna ni de internet.
- Implementación sencilla, cada tótem es replicable como una unidad.
Limitaciones
- Los precios y promociones se actualizan máquina por máquina.
- Si un técnico olvida un tótem, dos equipos contiguos pueden vender el mismo SKU a distinto precio.
- Los reportes por sucursal se arman extrayendo cada tótem por separado o esperando un proceso batch nocturno.
- Sin visibilidad corporativa en tiempo real.
Lectura Pulpa: Es el punto de partida ya adjudicado, pero deja de ser sostenible cuando MrJoy necesita gobernar precios y ver ventas a nivel país.
Esfuerzo adicional: Escenario ya contratado y en ejecución. No requiere horas adicionales.
0 h
Horas de desarrollo
CASO 2
Base de datos local compartida por tienda
Escenario preferido actualmente por el cliente
Diagrama de flujo · equipo técnico
Cómo funciona el flujo
- 01Se instala un servidor central en el cuarto de sistemas de cada sucursal.
- 02Todos los tótems de esa tienda consultan y escriben contra esa única base MySQL local vía LAN.
- 03El POS sigue cobrando en el tótem, pero la venta queda registrada en el servidor de la tienda.
- 04Cada sucursal mantiene su propio servidor y su propia base de datos.
A favor
- Resuelve la consistencia de precios y promociones dentro de una misma sucursal.
- Los reportes por tienda son inmediatos y unificados dentro del local.
Limitaciones
- Cada tienda queda aislada del resto: no hay verdad única a nivel país.
- Las promociones nacionales se despliegan tienda por tienda, con riesgo de desincronización.
- Si cae el servidor local o la red interna, ningún tótem del local puede vender.
- Se agrega un punto único de falla nuevo (el servidor de tienda) sin resolver la visibilidad corporativa.
- Escalar a más sucursales multiplica servidores, mantenimiento y costos de soporte in-situ.
Lectura Pulpa: Mejora el Caso 1 dentro de una sucursal, pero mantiene el problema estructural: MrJoy corporativo sigue sin ver el país en tiempo real y aparece un nuevo punto de falla local.
Esfuerzo adicional: Horas adicionales sobre el proyecto vigente (Caso 1) para migrar a servidor local compartido por tienda.
+32 h
Horas de desarrollo
CASO 3
Base de datos centralizada en la nube + modo offline
Arquitectura recomendada por Pulpa
Diagrama de flujo · equipo técnico
Cómo funciona el flujo
- 01La verdad única del negocio vive en una base MySQL central alojada en la nube.
- 02Cada tótem conserva un clon miniatura local que funciona como caché de catálogo y cola de ventas.
- 03Cada venta se escribe simultáneamente en la cola local y se sincroniza online contra la nube, visible en tiempo real para el equipo corporativo.
- 04Si cae internet, el tótem sigue vendiendo contra su MySQL local sin mostrar error al cliente.
- 05Cuando la conexión se restablece, un proceso automático agrupa las ventas offline y las envía de golpe al backend cloud.
A favor
- Cambio de precio o promoción a nivel país con un solo clic desde el panel corporativo.
- Visibilidad de ventas en tiempo real para MrJoy central, sin esperar batch nocturno.
- Ningún tótem deja de vender por caída de internet: sigue operando en modo offline resiliente.
- No hay servidores físicos adicionales por sucursal que mantener.
- Escala natural: sumar un tótem o una sucursal no agrega infraestructura local nueva.
Limitaciones
- Requiere aprovisionar y operar un backend en la nube (costo recurrente a nombre de MrJoy).
- Introduce complejidad de sincronización y reconciliación que hay que diseñar bien desde el inicio.
Lectura Pulpa: Es el único escenario que combina control corporativo total con garantía técnica de continuidad de venta en la sucursal. Es la evolución natural del Caso 1 sin los límites del Caso 2.
Esfuerzo adicional: Horas adicionales sobre el proyecto vigente (Caso 1) para migrar a nube central con modo offline resiliente.
+44 h
Horas de desarrollo
Recomendación
Por qué recomendamos el Caso 3 antes que el Caso 2
Entendemos que el Caso 2 luce como el paso intuitivo: parece un avance frente al Caso 1 porque unifica los tótems dentro de una misma tienda. En la práctica, resuelve un problema local y crea dos nuevos: mantiene a MrJoy corporativo ciego frente al país e introduce un servidor físico por sucursal como nuevo punto único de falla.
Lo que el Caso 2 NO resuelve
- Visibilidad corporativa en tiempo real de ventas a nivel país.
- Actualización nacional de precios y promociones con un solo clic.
- Escalabilidad limpia al abrir nuevas sucursales.
- Continuidad de venta si falla el servidor local (introduce ese riesgo nuevo).
Lo que el Caso 3 sí garantiza
- Verdad única del negocio en la nube, visible en tiempo real.
- Modo offline nativo: el tótem sigue vendiendo aunque caiga internet.
- Sin servidores físicos nuevos por sucursal que mantener.
- Base preparada para sumar canales (web, app, reportería BI) más adelante.
En síntesis: el Caso 3 cuesta un esfuerzo comparable al Caso 2, pero entrega el control corporativo que MrJoy necesita y la resiliencia operativa que la sucursal necesita. Por eso lo recomendamos como la ruta correcta.
Extensión
Esfuerzo estimado para llevarlo al Caso 3
Extensión sobre el proyecto vigente
Migración de Caso 1 a Caso 3 — nube central + modo offline
Incluye rediseño de arquitectura, backend cloud con panel de precios, cliente híbrido en el tótem con cola offline y QA de resiliencia con piloto en una sucursal.
Total estimado
+44 h
Horas de Desarrollo
El detalle económico, condiciones de pago y cronograma se formalizan en un change order aparte una vez que MrJoy confirme la ruta seleccionada.
Pulpa AgenciaDocumento consultivo válido por 15 días desde la fecha de emisión.