Что такое идемпотентность, и как ключи идемпотентности делают повторные запросы безопасными?

Question

IT Interview Practice · Accepted Answer

**Idempotency** (идемпотентность) означает, что выполнение операции **несколько раз даёт тот же эффект, что и выполнение один раз**. Это важно, потому что сети ненадёжны: когда клиент отправляет запрос, а ответ так и не приходит, он не может понять, обработал ли его сервер. Если он повторит, неидемпотентная операция может выполниться дважды.

## Проблема

```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` естественно идемпотентны, поэтому их повтор безопасен. `POST` — **нет**; именно отсюда берутся двойные списания и дублирующиеся заказы.

## Решение: idempotency keys

Клиент генерирует **уникальный ключ** (обычно UUID) для логической операции и отправляет его в заголовке. Сервер хранит ключ вместе с результатом; если тот же ключ приходит снова, он возвращает **сохранённый** результат вместо повторного выполнения.

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

**Тот же ключ** при повторе даёт тот же `200` и тот же платёж — клиент списан один раз. Именно так работает API Stripe.

## Почему это важно

Этот вопрос отделяет инженеров, проектирующих для happy path, от тех, кто проектирует для **отказа**, а именно в этом суть надёжности production. Распределённые системы гарантируют, что таймауты и частичные отказы *будут* случаться, поэтому любой endpoint с побочными эффектами — платежи, заказы, перевод денег — нуждается в стратегии повторов, а «просто повтори» опасно для `POST`. Интервьюер хочет услышать двучастное озарение: во-первых, что идемпотентность — это свойство, которое можно *заложить в проект* (делая `PUT`/`DELETE` естественно безопасными и давая `POST` **idempotency key**, когда он таковым быть не может), и во-вторых, тонкую деталь конкурентности — два повтора, пришедшие одновременно, не должны оба выполниться, поэтому проверке ключа и записи нужен lock или unique constraint. Правильная реализация — это разница между списанием с клиента один раз и списанием дважды, поэтому каждый серьёзный платёжный и коммерческий API это реализует.

Проблема

Решение: idempotency keys

Почему это важно

Похожие вопросы