Cosa significa davvero «funziona offline» per una cassa di ristorante

Ogni cassa cloud dichiara di funzionare offline. Pochissime spiegano cosa copra quella frase, e la distanza tra promessa e comportamento si scopre nella peggiore serata dell’anno.

L’offline è un problema di coda, non di schermata

Qualsiasi app può mettere in cache il menu e disegnare una schermata senza connessione. È la metà facile. La metà difficile è cosa succede ai venti ordini, quattro resi e un turno chiuso creati mentre la linea era giù.

Non sono schermate. Sono fatti da cui dipendono i numeri di altre persone: magazzino, cucina, contabilità, cassetto. Riportarli nell’ordine giusto, esattamente una volta, è tutto il problema ingegneristico.

Cosa deve continuare a fare la cassa

Senza internet, un punto vendita deve ancora:

• Aprire un turno e registrare il fondo cassa.
• Mostrare l’intero menu, con prezzi, varianti, taglie e combo.
• Prendere ordini, sospenderli, dividere conti, applicare sconti e codici promozionali.
• Incassare in contanti e stampare la ricevuta su una stampante collegata localmente.
• Annullare e rimborsare con le stesse regole di approvazione.
• Continuare a contare il cassetto perché la chiusura torni.

Questo è un ristorante che funziona. Nulla di quell’elenco ha bisogno di un server per essere vero.

Cosa sinceramente non può funzionare

L’onestà qui è una funzione, non una debolezza:

• Carte e pagamenti online. L’autorizzazione richiede il gateway. Incassi contanti, o carta al ritorno della linea.
• Viste live tra sedi. Il magazzino di un’altra sede è un fatto che vive sul server.
• Tutto ciò che un secondo dispositivo deve vedere subito. Un monitor cucina sulla stessa rete locale può ancora essere servito; un telefono in rete dati no.

Un sistema che sostiene che tutto questo funzioni offline sbaglia, o sta ridefinendo la parola.

Come viene resa sicura la ripartenza

Al ritorno della connessione il dispositivo non si limita a rispedire. Ogni azione è stata scritta localmente come record immutabile nel momento in cui è avvenuta, con:

Il server le salva con una chiave univoca su (deviceId, clientActionId). Se la stessa azione arriva due volte — wifi ballerino, riavvio dell’app, un tentativo impaziente — la seconda viene riconosciuta e viene restituito il risultato originale, invece di creare un secondo ordine. I pagamenti portano una chiave di idempotenza per lo stesso motivo: un retry non può addebitare due volte.

I tentativi si diradano progressivamente anziché martellare la connessione, e ciò che continua a fallire oltre la soglia finisce in una coda morta che un responsabile vede e risolve, invece di sparire in silenzio.

Quando due casse si contraddicono

È la domanda che vale la pena porre a qualsiasi fornitore. Due casse offline. Entrambe vendono le ultime cinque porzioni del piatto del giorno. Entrambe rientrano insieme.

Non c’è risposta magica: le porzioni non esistono. Conta che il sistema sia deterministico e te lo dica:

• Il magazzino che andrebbe in negativo viene rifiutato con un errore azionabile, non accettato in silenzio.
• Lo stato dell’ordine si muove solo su transizioni valide: una comanda «servita» non si riapre.
• Un pagamento superiore al totale viene rifiutato.
• Lo stato dei tavoli prende la versione autorevole del server: due persone non possono sedere al tavolo 6.

Dovrai comunque offrire un piatto. Ma lo saprai nel momento del conflitto, non trovando una riga di magazzino negativa tre settimane dopo.

Il test di un minuto

Prima di firmare con chiunque, fai questo nella demo: metti il tablet in modalità aereo, prendi quattro ordini, rimborsane uno, chiudi il turno, poi riattiva la connessione. Poi guarda tre schermate — magazzino, storico cucina e vendite del giorno — e verifica che i quattro ordini ci siano, una volta ciascuno, nell’ordine giusto, con il reso stornato.

Quel test dura un minuto e dice più di qualunque elenco di funzioni.