რა არის idempotency და როგორ ხდის idempotency key-ები retry-ებს უსაფრთხოს?

Question

IT Interview Practice · Accepted Answer

**Idempotency** ნიშნავს, რომ ოპერაციის **მრავალჯერ შესრულებას იგივე ეფექტი აქვს, რაც ერთხელ შესრულებას**. ის მნიშვნელოვანია, რადგან ქსელები არასაიმედოა: როცა client აგზავნის request-ს და response ვერასდროს მოდის, მას არ შეუძლია იმის გარჩევა, დაამუშავა თუ არა server ის. თუ ის იმეორებს, არა-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-ია, ამიტომ მათი გამეორება უსაფრთხოა. `POST` **არ არის** — სწორედ აქედან მოდის დუბლირებული ჩამოჭრები და დუბლირებული order-ები.

## გამოსავალი: idempotency key-ები

client-ი წარმოქმნის **უნიკალურ key-ს** (ჩვეულებრივ UUID) ლოგიკური ოპერაციისთვის და აგზავნის მას header-ში. server ინახავს key-ს შედეგთან ერთად; თუ იგივე key ხელახლა მოვა, ის **შენახულ** შედეგს აბრუნებს ხელახლა შესრულების ნაცვლად.

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

**იმავე key** გამეორებისას იმავე `200`-ს და იმავე payment-ს იძლევა — მომხმარებელს ერთხელ ეჭრება. სწორედ ასე მუშაობს Stripe-ის API.

## რატომ არის ეს მნიშვნელოვანი

ეს კითხვა აშორებს ინჟინრებს, რომლებიც happy path-ისთვის აპროექტებენ, მათგან, რომლებიც **ხარვეზისთვის** აპროექტებენ, რაც production-ის საიმედოობის არსია. განაწილებული სისტემები გარანტიას იძლევიან, რომ timeout-ები და ნაწილობრივი ხარვეზები *მოხდება*, ამიტომ ნებისმიერ endpoint-ს side effect-ებით — payment-ები, order-ები, ფულის გაგზავნა — სჭირდება retry-ის სტრატეგია, და „უბრალოდ გაიმეორე" საშიშია `POST`-ისთვის. ინტერვიუერს სურს ორნაწილიანი აზრის მოსმენა: პირველი, რომ idempotency არის თვისება, რომელიც *ჩადგმით* შეგიძლიათ (`PUT`/`DELETE`-ის ბუნებრივად უსაფრთხოდ ქცევა და `POST`-ისთვის **idempotency key**-ს მიცემა, როცა ის თავად ვერ ხდება უსაფრთხო), და მეორე, დახვეწილი concurrency-ის დეტალი — ერთდროულად მოსული ორი retry არ უნდა შესრულდეს ორივე, ამიტომ key-ის შემოწმებას და ჩაწერას სჭირდება lock ან unique constraint. ამის სწორად გაკეთება არის განსხვავება მომხმარებლის ერთხელ და ორჯერ ჩამოჭრას შორის, რის გამოც ყოველი სერიოზული payment-ისა და commerce API-ს ახორციელებს მას.

პრობლემა

გამოსავალი: idempotency key-ები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები