Idempotency là gì, và idempotency key làm retry an toàn ra sao?

Question

IT Interview Practice · Accepted Answer

**Idempotency** nghĩa là thực hiện một thao tác **nhiều lần cho cùng kết quả như thực hiện một lần**. Nó quan trọng vì mạng không đáng tin: khi client gửi request mà response không bao giờ tới, nó không biết server đã xử lý hay chưa. Nếu retry, một thao tác không idempotent có thể chạy hai lần.

## Vấn đề

```text
Client ──POST /payments {$100}──▶ Server   (trừ $100 ✓)
Client ◀────────X (timeout)────── Server   (response bị mất)
Client ──POST /payments {$100}──▶ Server   (trừ $100 LẦN NỮA ✗ → $200!)
```

`GET`, `PUT` và `DELETE` vốn idempotent nên retry chúng an toàn. `POST` thì **không** — đây chính là nơi sinh ra trừ tiền trùng và order trùng.

## Giải pháp: idempotency key

Client sinh một **key duy nhất** (thường là UUID) cho thao tác logic đó và gửi trong header. Server lưu key kèm kết quả; nếu cùng key tới lại, nó trả **kết quả đã lưu** thay vì thực thi lại.

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

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

```text
Logic server khi nhận request có Idempotency-Key:
  1. Tra key trong store (vd. Redis/DB).
  2. Nếu có → trả response đã lưu (không trừ lại).            ← trường hợp retry
  3. Nếu chưa → xử lý, lưu (key → response), rồi trả về.
  (Bọc bước 3 trong transaction / lock để retry đồng thời không thực thi hai lần.)
```

**Cùng key** khi retry cho cùng `200` và cùng một payment — khách chỉ bị trừ một lần. Đây đúng là cách API của Stripe hoạt động.

## Tại sao điều này quan trọng

Câu này tách kỹ sư thiết kế cho happy path khỏi người thiết kế cho **thất bại**, vốn là bản chất của độ tin cậy production. Hệ phân tán đảm bảo timeout và lỗi một phần *sẽ* xảy ra, nên bất kỳ endpoint có side effect nào — thanh toán, order, chuyển tiền — đều cần chiến lược retry, và "cứ retry" là nguy hiểm với `POST`. Người phỏng vấn muốn nghe hai ý: thứ nhất, idempotency là thuộc tính bạn *thiết kế được* (làm `PUT`/`DELETE` vốn an toàn, và cấp cho `POST` một **idempotency key** khi nó không tự an toàn); thứ hai, chi tiết concurrency tinh tế — hai retry tới cùng lúc không được cùng thực thi, nên bước kiểm tra key và bước ghi cần lock hoặc unique constraint. Làm đúng chỗ này là ranh giới giữa trừ tiền khách một lần và trừ hai lần, đó là lý do mọi API thanh toán và thương mại nghiêm túc đều triển khai nó.

Vấn đề

Giải pháp: idempotency key

Tại sao điều này quan trọng

Câu hỏi liên quan