Apa itu idempotency, dan bagaimana idempotency key membuat retry aman?

Question

IT Interview Practice · Accepted Answer

**Idempotency** berarti melakukan sebuah operasi **berkali-kali memiliki efek yang sama dengan melakukannya sekali**. Ini penting karena jaringan tidak dapat diandalkan: ketika client mengirim sebuah request dan response tidak pernah tiba, ia tidak bisa tahu apakah server telah memprosesnya. Jika ia retry, operasi non-idempotent mungkin berjalan dua kali.

## Masalahnya

```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`, dan `DELETE` secara alami idempotent, sehingga me-retry mereka aman. `POST` **tidak** — inilah persis dari mana charge duplikat dan order duplikat berasal.

## Solusinya: idempotency key

Client menghasilkan sebuah **key unik** (biasanya UUID) untuk operasi logis tersebut dan mengirimnya dalam sebuah header. Server menyimpan key beserta hasilnya; jika key yang sama tiba lagi, ia mengembalikan hasil yang **tersimpan** alih-alih mengeksekusi ulang.

```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 yang sama** saat retry menghasilkan `200` yang sama dan payment yang sama — pelanggan dikenai charge sekali. Inilah persis cara kerja API Stripe.

## Mengapa ini penting

Pertanyaan ini memisahkan engineer yang mendesain untuk happy path dari mereka yang mendesain untuk **kegagalan**, yang merupakan inti keandalan produksi. Sistem terdistribusi menjamin bahwa timeout dan kegagalan parsial *akan* terjadi, sehingga endpoint apa pun dengan side effect — payment, order, mengirim uang — membutuhkan strategi retry, dan "retry saja" berbahaya untuk `POST`. Pewawancara ingin mendengar wawasan dua bagian: pertama, bahwa idempotency adalah properti yang bisa Anda *rancang* (membuat `PUT`/`DELETE` aman secara alami, dan memberi `POST` sebuah **idempotency key** ketika ia tidak bisa); dan kedua, detail concurrency yang halus — dua retry yang tiba bersamaan tidak boleh keduanya dieksekusi, sehingga pemeriksaan key dan penulisannya membutuhkan lock atau unique constraint. Melakukan ini dengan benar adalah perbedaan antara mengenai charge pelanggan sekali dan dua kali, itulah mengapa setiap API payment dan commerce yang serius mengimplementasikannya.

Masalahnya

Solusinya: idempotency key

Mengapa ini penting

Pertanyaan terkait