Τι είναι το idempotency, και πώς τα idempotency keys κάνουν τα retries ασφαλή;

Question

IT Interview Practice · Accepted Answer

Το **idempotency** σημαίνει ότι η εκτέλεση μιας λειτουργίας **πολλές φορές έχει το ίδιο αποτέλεσμα με την εκτέλεσή της μία φορά**. Έχει σημασία επειδή τα δίκτυα είναι αναξιόπιστα: όταν ένας client στέλνει ένα request και η απόκριση δεν φτάνει ποτέ, δεν μπορεί να ξέρει αν ο server το επεξεργάστηκε. Αν κάνει retry, μια μη idempotent λειτουργία μπορεί να τρέξει δύο φορές.

## Το πρόβλημα

```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`, και `DELETE` είναι φυσικά idempotent, οπότε το retry τους είναι ασφαλές. Το `POST` **δεν** είναι — από εδώ ακριβώς προέρχονται οι διπλές χρεώσεις και τα διπλά orders.

## Η λύση: idempotency keys

Ο client παράγει ένα **μοναδικό κλειδί** (συνήθως ένα UUID) για τη λογική λειτουργία και το στέλνει σε ένα header. Ο server αποθηκεύει το κλειδί μαζί με το αποτέλεσμα· αν το ίδιο κλειδί φτάσει ξανά, επιστρέφει το **αποθηκευμένο** αποτέλεσμα αντί να το εκτελέσει ξανά.

```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.)
```

Το **ίδιο κλειδί** στο retry αποδίδει το ίδιο `200` και την ίδια πληρωμή — ο πελάτης χρεώνεται μία φορά. Έτσι ακριβώς λειτουργεί το API του Stripe.

## Γιατί έχει σημασία

Αυτή η ερώτηση ξεχωρίζει τους μηχανικούς που σχεδιάζουν για το happy path από εκείνους που σχεδιάζουν για την **αποτυχία**, που είναι το ζητούμενο της αξιοπιστίας στην παραγωγή. Τα κατανεμημένα συστήματα εγγυώνται ότι timeouts και μερικές αποτυχίες *θα* συμβούν, οπότε κάθε endpoint με παρενέργειες — πληρωμές, orders, αποστολή χρημάτων — χρειάζεται μια στρατηγική retry, και το "απλώς κάνε retry" είναι επικίνδυνο για το `POST`. Ο συνεντευξιαστής θέλει να ακούσει τη διμερή διορατικότητα: πρώτον, ότι το idempotency είναι μια ιδιότητα που μπορείτε να *σχεδιάσετε* (κάνοντας τα `PUT`/`DELETE` φυσικά ασφαλή, και δίνοντας στο `POST` ένα **idempotency key** όταν δεν μπορεί να είναι), και δεύτερον, τη λεπτή λεπτομέρεια ταυτοχρονισμού — δύο retries που φτάνουν ταυτόχρονα δεν πρέπει να εκτελεστούν και τα δύο, οπότε ο έλεγχος του κλειδιού και η εγγραφή χρειάζονται ένα lock ή unique constraint. Το να το κάνετε αυτό σωστά είναι η διαφορά ανάμεσα στο να χρεώσετε έναν πελάτη μία φορά και στο να τον χρεώσετε δύο, γι' αυτό κάθε σοβαρό API πληρωμών και εμπορίου το υλοποιεί.

Το πρόβλημα

Η λύση: idempotency keys

Γιατί έχει σημασία

Σχετικές ερωτήσεις