Comanda trimisă de două ori: ce să ceri furnizorului de software
Dacă aplicația nu confirmă trimiterea, un al doilea click poate dubla marfa pregătită. Ce să verifici când cumperi un sistem pentru firmă.
Un angajat trimite o comandă către depozit, dar aplicația nu îi confirmă trimiterea. Apasă din nou „Trimite”. Dacă sistemul înregistrează două comenzi, depozitul poate pregăti de două ori aceeași marfă. Când cumperi software pentru firma ta, ce îi ceri furnizorului ca să prevină această dublare?
În acest exemplu ipotetic, depozitul a primit deja prima cerere. S-a pierdut doar răspunsul. Dacă aplicația tratează al doilea click drept o comandă nouă, aceeași marfă poate intra de două ori în pregătire. Omul trebuie acum să ghicească starea sistemului înainte să-și continue munca.
Când cumperi un sistem custom, cere să vezi ce se întâmplă în această pauză dintre operație și confirmare. Acolo se decide dacă reluarea ajută sau complică situația.
Lipsa răspunsului nu dovedește eșecul
O cerere poate să nu ajungă la destinație. Poate și să ajungă, să fie executată, iar confirmarea să întârzie ori să se piardă. Mesajul „timp de așteptare depășit” nu distinge singur cele două cazuri.
De aceea, dezactivarea butonului după primul click rezolvă doar o parte a problemei. O reîncercare poate veni și după redeschiderea paginii sau din integrarea dintre două servicii. Protecția trebuie să existe acolo unde se înregistrează operația.
Aceeași intenție trebuie recunoscută
O soluție este atribuirea unui identificator stabil operației dorite. Reluarea păstrează acel identificator; serviciul îl recunoaște și poate întoarce rezultatul existent în loc să creeze o operație nouă. Acesta este sensul practic al idempotenței în acest context.
AWS explică acest mecanism prin identificatori de cerere furnizați de apelant. Două cereri cu date identice nu exprimă obligatoriu aceeași intenție: un cumpărător poate dori legitim două comenzi identice. Identificatorul trebuie să distingă o reluare de o comandă nouă.
Protecția are și limite care trebuie stabilite. Cât timp se păstrează identificatorul? Ce se întâmplă când aceeași cheie vine cu alte date? Cine verifică rezultatul dacă un serviciu extern nu răspunde? Stripe documentează atât reutilizarea răspunsului pentru cereri repetate în API v1, cât și condițiile de păstrare a cheilor. Nu presupune că orice integrare oferă automat aceeași protecție.
Cere o demonstrație cu răspunsul întrerupt
La următoarea demonstrație, alege o operație care contează pentru firmă. Pentru comanda către depozit, propune această probă într-un mediu de test:
- Sistemul înregistrează comanda, dar confirmarea către aplicație este întreruptă.
- Operatorul reia trimiterea aceleiași comenzi, inclusiv după reîncărcarea paginii.
- Echipa arată o singură comandă în depozit, încercările asociate ei și starea afișată operatorului.
- Operatorul inițiază apoi intenționat o comandă nouă, cu aceleași produse. Aceasta trebuie să rămână posibilă.
Verifică separat efectele din aval: o singură comandă în aplicație nu dovedește că s-a creat un singur aviz sau că s-a trimis o singură solicitare curierului. Fiecare graniță poate avea propriul mecanism de reluare.
Dacă rezultatul rămâne incert, interfața trebuie să arate că operația este în verificare și cine o poate lămuri. Un buton disponibil fără această explicație transferă decizia tehnică la operator.
Pune proba în criteriile de acceptare
Înainte să accepți integrarea, notează operația, identificatorul, durata protecției și modul de verificare a rezultatului. Cere echipei să demonstreze scenariul, nu doar să confirme existența unui mecanism de retry.
La SurCod, construirea sistemelor adaptate afacerii pornește de la limite clare între componente. Pentru o discuție despre proiectul tău, adu o operație concretă la care oamenii întreabă astăzi „o fi mers?”. Putem porni conversația de la acel traseu și de la dovada pe care trebuie să o ofere sistemul. Descrie-ne situația.
Referințele tehnice au fost consultate la 20 octombrie 2026.