Idempotența e ușoară până când a doua cerere e diferită

Toată lumea știe că idempotența înseamnă că o cerere repetată dă același rezultat ca prima. Sună simplu, ca și cum ai apăsa de două ori butonul liftului. Dar în realitate, seamănă mai degrabă cu încercarea de a asambla un dulap IKEA fără instrucțiuni: aceleași piese, dar rezultatul e diferit.

În practică, idempotența se strică atunci când a doua cerere vine cu date diferite. De exemplu, clientul trimite același identificator de idempotență, dar cu corpul modificat. Serverul trebuie să decidă: să ignore noul corp sau să-l trateze ca o cerere nouă? Ambele opțiuni pot duce la consecințe neașteptate.

Autorul articolului analizează scenarii tipice: de la simplul POST repetat până la cazuri complexe cu actualizări parțiale. E și mai dureros când intri în joc sistemele distribuite — aici nu mai e de glumit, fiecare cerere în plus poate provoca o cascadă de erori, ca și cum ai trimite din greșeală un email cu un bug critic tuturor clienților.

Concluzia principală: idempotența nu e doar un protocol, ci o decizie arhitecturală. Dacă crezi că e suficient să adaugi un câmp idempotency_key în baza de date, te așteaptă o surpriză. Ca și în cazul unui deploy nocturn, mai bine măsori de șapte ori decât să rezolvi un incident de producție la 3 dimineața.

Comentariul studioului METABYTE: Idempotența e genul de subiect pe care mulți developeri îl amână „pentru mai târziu”, până când se confruntă cu plăți duplicate sau comenzi stricate. La METABYTE, includem idempotența în arhitectură de la bun început — e mai ieftin decât să explici clientului de ce i s-a debitat de două ori.