Çfarë është idempotency, dhe si i bëjnë idempotency keys retry-t të sigurta?

Question

IT Interview Practice · Accepted Answer

**Idempotency** do të thotë se kryerja e një operacioni **shumë herë ka të njëjtin efekt si kryerja e tij një herë**. Ka rëndësi sepse rrjetet janë të pabesueshme: kur një client dërgon një request dhe response-i nuk mbërrin kurrë, ai nuk e di dot nëse serveri e përpunoi. Nëse ribën (retry), një operacion jo-idempotent mund të ekzekutohet dy herë.

## Problemi

```text
Client ──POST /payments {$100}──▶ Server   (charges $100 ✓)
Client ◀────────X (timeout)────── Server   (response lost)
Client ──POST /payments {$100}──▶ Server   (charges $100 AGAIN ✗ → $200!)
```

`GET`, `PUT`, dhe `DELETE` janë natyrshëm idempotent, prandaj ribërja e tyre është e sigurt. `POST` **nuk** është — pikërisht nga këtu vijnë tarifimet e dyfishta dhe orders të dyfishta.

## Zgjidhja: idempotency keys

Client-i gjeneron një **çelës unik** (zakonisht një UUID) për operacionin logjik dhe e dërgon në një header. Serveri e ruan çelësin bashkë me rezultatin; nëse i njëjti çelës mbërrin sërish, kthen rezultatin **e ruajtur** në vend që të riekzekutohet.

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

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

```text
Server logic on receiving a request with an Idempotency-Key:
  1. Look up the key in a store (e.g. Redis/DB).
  2. If found → return the saved response (no re-charge).      ← the retry case
  3. If not  → process, save (key → response), then return.
  (Wrap 3 in a transaction / lock so concurrent retries don't double-execute.)
```

**I njëjti çelës** në retry jep të njëjtin `200` dhe të njëjtin payment — klienti tarifohet një herë. Pikërisht kështu funksionon API-ja e Stripe.

## Pse ka rëndësi

Kjo pyetje ndan inxhinierët që projektojnë për happy path nga ata që projektojnë për **dështim**, që është thelbi i besueshmërisë në production. Sistemet e shpërndara garantojnë se timeouts dhe dështime të pjesshme *do të* ndodhin, prandaj çdo endpoint me efekte anësore — payments, orders, dërgim parash — ka nevojë për një strategji retry, dhe "thjesht ribëj" është e rrezikshme për `POST`. Intervistuesi do të dëgjojë njohurinë me dy pjesë: së pari, se idempotency është një veti që mund ta *fusësh në dizajn* (duke i bërë `PUT`/`DELETE` natyrshëm të sigurta, dhe duke i dhënë `POST` një **idempotency key** kur nuk mundet), dhe së dyti, detajin delikat të concurrency-t — dy retry që mbërrijnë njëkohësisht nuk duhet të ekzekutohen të dyja, prandaj kontrolli i çelësit dhe shkrimi kanë nevojë për një lock ose unique constraint. Ta bësh këtë saktë është ndryshimi midis tarifimit të një klienti një herë dhe tarifimit dy herë, prandaj çdo API serioz payments dhe commerce e implementon.

Problemi

Zgjidhja: idempotency keys

Pse ka rëndësi

Pyetje të ngjashme