Ce este idempotency și cum fac idempotency key-urile ca retry-urile să fie sigure?

Question

IT Interview Practice · Accepted Answer

**Idempotency** înseamnă că efectuarea unei operații **de mai multe ori are același efect ca efectuarea ei o singură dată**. Contează pentru că rețelele sunt nefiabile: când un client trimite o cerere și răspunsul nu ajunge niciodată, nu poate spune dacă serverul a procesat-o. Dacă reîncearcă, o operație non-idempotentă ar putea rula de două ori.

## Problema

```text
Client ──POST /payments {$100}──▶ Server   (percepe $100 ✓)
Client ◀────────X (timeout)────── Server   (răspuns pierdut)
Client ──POST /payments {$100}──▶ Server   (percepe $100 DIN NOU ✗ → $200!)
```

`GET`, `PUT` și `DELETE` sunt idempotente în mod natural, așa că reîncercarea lor este sigură. `POST` **nu** este — exact de aici provin percepțiile duble și comenzile duplicate.

## Soluția: idempotency key-uri

Clientul generează o **cheie unică** (de obicei un UUID) pentru operația logică și o trimite într-un header. Serverul stochează cheia împreună cu rezultatul; dacă aceeași cheie sosește din nou, returnează rezultatul **stocat** în loc să re-execute.

```http
POST /payments HTTP/1.1
Idempotency-Key: 5f2b8c1e-3a4d-4e6f-9c0b-1a2b3c4d5e6f
Content-Type: application/json

{ "amount": 100, "currency": "usd" }
```

```text
Logica serverului la primirea unei cereri cu un Idempotency-Key:
  1. Caută cheia într-un store (ex. Redis/DB).
  2. Dacă e găsită → returnează răspunsul salvat (fără reîncasare).      ← cazul de retry
  3. Dacă nu     → procesează, salvează (cheie → răspuns), apoi returnează.
  (Împachetează pasul 3 într-o tranzacție / lock ca retry-urile concurente să nu execute de două ori.)
```

**Aceeași cheie** la retry produce același `200` și aceeași plată — clientul este taxat o singură dată. Exact așa funcționează API-ul Stripe.

## De ce contează

Această întrebare separă inginerii care proiectează pentru calea fericită de cei care proiectează pentru **eșec**, ceea ce înseamnă de fapt fiabilitatea în producție. Sistemele distribuite garantează că timeout-urile și eșecurile parțiale *se vor* întâmpla, așa că orice endpoint cu efecte secundare — plăți, comenzi, trimitere de bani — are nevoie de o strategie de retry, iar „doar reîncearcă" este periculos pentru `POST`. Intervievatorul vrea să audă înțelegerea în două părți: în primul rând, că idempotency este o proprietate pe care o poți *proiecta* (făcând `PUT`/`DELETE` sigure în mod natural și dând lui `POST` un **idempotency key** când nu poate fi), și în al doilea rând, detaliul subtil de concurență — două retry-uri care sosesc simultan nu trebuie să se execute ambele, așa că verificarea cheii și scrierea au nevoie de un lock sau o constrângere unique. A nimeri asta corect este diferența dintre a taxa un client o dată și a-l taxa de două ori, de aceea fiecare API serios de plăți și comerț o implementează.

Problema

Soluția: idempotency key-uri

De ce contează

Întrebări conexe