idempotency คืออะไร และ idempotency key ทำให้การ retry ปลอดภัยอย่างไร?

Question

IT Interview Practice · Accepted Answer

**Idempotency** หมายถึงการทำการกระทำหนึ่ง **หลายครั้งให้ผลเหมือนทำครั้งเดียว** มันสำคัญเพราะเครือข่ายไม่น่าเชื่อถือ: เมื่อ client ส่ง request แล้ว response ไม่เคยมาถึง มันบอกไม่ได้ว่า 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` **ไม่ใช่** — นี่แหละคือแหล่งกำเนิดของการเรียกเก็บเงินซ้ำและ 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 เดิม** เมื่อ retry จะให้ `200` เดิมและ payment เดิม — ลูกค้าถูกเรียกเก็บเงินครั้งเดียว นี่คือวิธีที่ API ของ Stripe ทำงานเป๊ะ ๆ

## ทำไมจึงสำคัญ

คำถามนี้แยกวิศวกรที่ออกแบบเพื่อ happy path ออกจากคนที่ออกแบบเพื่อ **ความล้มเหลว** ซึ่งคือแก่นของความน่าเชื่อถือใน production ระบบกระจาย (distributed systems) รับประกันว่า timeout และความล้มเหลวบางส่วน *จะ* เกิด ดังนั้น endpoint ใดที่มี side effect — การชำระเงิน, order, การโอนเงิน — จึงต้องมีแผน retry และ "แค่ retry" เป็นอันตรายสำหรับ `POST` ผู้สัมภาษณ์อยากได้ยินสองข้อคิด: หนึ่ง idempotency เป็นคุณสมบัติที่คุณ *ออกแบบใส่เข้าไปได้* (ทำให้ `PUT`/`DELETE` ปลอดภัยโดยธรรมชาติ และมอบ **idempotency key** ให้ `POST` เมื่อมันปลอดภัยเองไม่ได้); และสอง รายละเอียด concurrency ที่ละเอียดอ่อน — retry สองครั้งที่มาถึงพร้อมกันต้องไม่รันทั้งคู่ ดังนั้นการเช็ค key และการเขียนจึงต้องมี lock หรือ unique constraint การทำถูกตรงนี้คือความต่างระหว่างการเรียกเก็บเงินลูกค้าครั้งเดียวกับสองครั้ง จึงเป็นเหตุว่าทำไมทุก API ด้านการชำระเงินและการค้าอย่างจริงจังจึงนำมาใช้

ปัญหา

ทางแก้: idempotency key

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง