Ce înseamnă cu adevărat „funcționează offline” pentru un POS de restaurant

Orice POS din cloud spune că funcționează offline. Foarte puține explică ce acoperă acea propoziție, iar distanța dintre promisiune și comportament se descoperă în cea mai proastă seară a anului.

Offline-ul e o problemă de coadă, nu de ecran

Orice aplicație poate pune meniul în cache și desena un ecran fără conexiune. Asta e jumătatea ușoară. Cea grea e ce se întâmplă cu cele douăzeci de comenzi, patru restituiri și o tură închisă create cât linia a fost picată.

Nu sunt ecrane. Sunt fapte de care depind cifrele altor oameni — stocul, bucătăria, registrele, sertarul de casă. Aducerea lor înapoi în ordinea corectă, exact o dată, e toată problema de inginerie.

Ce trebuie să facă în continuare casa

Fără internet, un punct de vânzare trebuie totuși să:

• Deschidă o tură și să înregistreze fondul de casă.
• Afișeze meniul complet, cu prețuri, opțiuni, mărimi și meniuri combo.
• Preia comenzi, să le rețină, să împartă note, să aplice reduceri și coduri promoționale.
• Încaseze numerar și să tipărească bonul pe o imprimantă conectată local.
• Anuleze și restituie cu aceleași reguli de aprobare.
• Numere în continuare sertarul, ca închiderea să iasă.

Ăsta e un restaurant funcțional. Nimic din listă nu are nevoie de un server ca să fie adevărat.

Ce chiar nu poate funcționa

Onestitatea e aici o funcție, nu o slăbiciune:

• Cardul și plățile online. O autorizare are nevoie de gateway. Iei numerar, sau cardul când revine linia.
• Vederile live între locații. Stocul altei filiale e un fapt care trăiește pe server.
• Orice trebuie văzut instantaneu de un al doilea dispozitiv. Un ecran de bucătărie din aceeași rețea locală poate fi servit; un telefon pe date mobile, nu.

Un sistem care pretinde că toate acestea merg offline fie greșește, fie redefinește cuvântul.

Cum e făcută sigură recuperarea

Când revine conexiunea, dispozitivul nu retrimite pur și simplu. Fiecare acțiune a fost scrisă local ca înregistrare imuabilă în momentul în care s-a produs, purtând:

Serverul le stochează cu o cheie unică pe (deviceId, clientActionId). Dacă aceeași acțiune ajunge de două ori — wifi instabil, repornirea aplicației, o reîncercare nerăbdătoare — a doua este recunoscută și se returnează rezultatul original, în loc să se creeze o a doua comandă. Plățile poartă o cheie de idempotență din același motiv: o reîncercare nu poate debita de două ori.

Reîncercările se răresc treptat în loc să bombardeze conexiunea, iar ce eșuează în continuare după prag ajunge într-o coadă moartă pe care un manager o vede și o rezolvă, în loc să dispară în tăcere.

Când două case se contrazic

Asta e întrebarea care merită pusă oricărui furnizor. Două case offline. Amândouă vând ultimele cinci porții din preparatul zilei. Amândouă revin în același timp.

Nu există răspuns magic — porțiile nu există. Contează ca sistemul să fie determinist și să ți-o spună:

• Stocul care ar deveni negativ e respins cu o eroare acționabilă, nu acceptat în tăcere.
• Starea comenzii se mișcă doar pe tranziții valide: un bon „servit” nu se redeschide.
• O plată mai mare decât totalul comenzii e respinsă.
• Starea meselor ia versiunea autoritară a serverului, pentru că doi oameni nu pot sta la masa 6.

Tot va trebui să oferi un preparat din partea casei. Dar vei ști în momentul conflictului, nu găsind un rând de stoc negativ trei săptămâni mai târziu.

Testul de un minut

Înainte să semnezi cu cineva, fă asta în demo: pune tableta pe modul avion, ia patru comenzi, restituie una, închide tura, apoi repornește conexiunea. Apoi verifică trei ecrane — stocul, istoricul bucătăriei și vânzările zilei — și vezi dacă toate cele patru comenzi sunt acolo, câte o dată fiecare, în ordinea corectă, cu restituirea stornată.

Testul durează un minut și îți spune mai mult decât orice listă de funcții.