Qué significa de verdad que un TPV de restaurante «funcione sin conexión»

Todos los TPV en la nube dicen que funcionan sin conexión. Muy pocos explican qué cubre esa frase, y la distancia entre la promesa y el comportamiento se descubre en la peor noche del año.

Lo offline es un problema de cola, no de pantalla

Cualquier app puede cachear la carta y pintar una pantalla sin conexión. Esa es la mitad fácil. La difícil es qué ocurre con los veinte pedidos, cuatro devoluciones y un turno cerrado que se crearon mientras la línea estaba caída.

No son pantallas. Son hechos de los que dependen los números de otras personas: el stock, la cocina, los libros, el cajón. Devolverlos en el orden correcto, exactamente una vez, es todo el problema de ingeniería.

Lo que la caja debe seguir haciendo

Sin internet, un punto de venta todavía tiene que:

• Abrir turno y registrar el fondo inicial.
• Mostrar la carta completa, con precios, modificadores, tamaños y menús.
• Tomar pedidos, retenerlos, dividir cuentas, aplicar descuentos y códigos promocionales.
• Cobrar en efectivo e imprimir el ticket en una impresora conectada localmente.
• Anular y devolver con las mismas reglas de aprobación.
• Seguir contando el cajón para que el cierre cuadre.

Eso es un restaurante funcionando. Nada de esa lista necesita un servidor para ser cierto.

Lo que sinceramente no puede funcionar

La honestidad aquí es una función, no una debilidad:

• Tarjeta y pagos online. Una autorización necesita la pasarela. Cobras en efectivo, o con tarjeta cuando vuelva la línea.
• Vistas entre locales en vivo. El stock de otra sucursal es un hecho que vive en el servidor.
• Cualquier cosa que un segundo dispositivo deba ver al instante. Una pantalla de cocina en la misma red local puede seguir sirviéndose; un móvil con datos no puede ser avisado por una caja sin enlace.

Un sistema que afirme que todo esto funciona sin conexión se equivoca, o redefine la palabra.

Cómo se hace segura la puesta al día

Al volver la conexión, el dispositivo no reenvía sin más. Cada acción se escribió localmente como un registro inmutable en el momento en que ocurrió, con:

El servidor las guarda con una clave única sobre (deviceId, clientActionId). Si la misma acción llega dos veces —wifi inestable, reinicio de la app, un reintento impaciente— la segunda se reconoce y se devuelve el resultado original en lugar de crear otro pedido. Los cobros llevan clave de idempotencia por lo mismo: un reintento no puede cargar dos veces.

Los reintentos se espacian progresivamente en vez de castigar la conexión, y lo que sigue fallando pasado el umbral queda en una cola muerta que un responsable ve y resuelve, en lugar de desaparecer en silencio.

Cuando dos cajas se contradicen

Esta es la pregunta que merece la pena hacer. Dos cajas sin conexión. Ambas venden las últimas cinco raciones del plato del día. Ambas vuelven a la vez.

No hay respuesta mágica: las raciones no existen. Lo que importa es que el sistema sea determinista y te lo diga:

• El stock que quedaría negativo se rechaza con un error accionable, no se acepta en silencio.
• El estado del pedido solo avanza por transiciones válidas: una comanda «servida» no se reabre.
• Un cobro mayor que el total del pedido se rechaza.
• El estado de mesas toma la versión del servidor, porque dos personas no pueden ocupar la mesa 6.

Aun así tendrás que invitar a un plato. Pero lo sabrás en el momento del conflicto, no al encontrar una línea de stock negativa tres semanas después.

La prueba de un minuto

Antes de firmar con nadie, haz esto en la demo: pon la tablet en modo avión, toma cuatro pedidos, devuelve uno, cierra el turno y vuelve a conectar. Después mira tres pantallas —stock, historial de cocina y ventas del día— y comprueba que los cuatro pedidos están, una vez cada uno, en el orden correcto y con la devolución revertida.

Esa prueba dura un minuto y dice más que cualquier lista de funciones.