Конкурентность и архитектура кеша для идемпотентности на масштабе

Два запроса с одним idempotency key прилетают на сервер одновременно — реальный сценарий, когда мобильный клиент стреляет двумя retry до первого подтверждения. Наивный SELECT-then-INSERT пропускает оба. Оба списывают с клиента.

Гонка в наивной реализации

Частая первая реализация:

-- Не атомарно!
SELECT * FROM idempotency_keys WHERE key = $1;
-- Здесь время течёт. Второй запрос проскакивает.
INSERT INTO idempotency_keys (key, fingerprint, status, expires_at)
  VALUES ($1, $2, 'in_progress', NOW() + interval '24 hours');

Между SELECT и INSERT второй конкурентный запрос может выполнить тот же SELECT (не увидев строки), потом тоже INSERT. Оба успешны. Оба начинают обработку. Оба списывают с клиента.

Фикс 1: Postgres INSERT … ON CONFLICT DO NOTHING RETURNING

INSERT INTO idempotency_keys (key, fingerprint, status, expires_at)
  VALUES ($1, $2, 'in_progress', NOW() + interval '24 hours')
  ON CONFLICT (key) DO NOTHING
  RETURNING *;

Если RETURNING пустой, этот запрос проиграл гонку. Он перечитывает строку:

• Если status=in_progress → вернуть 409 Conflict.
• Если status=completed → вернуть кешированный ответ.

INSERT атомарен на уровне базы. Гонки нет.

Фикс 2: Postgres advisory lock

SELECT pg_advisory_xact_lock(hashtext($1));
-- Теперь безопасно делать SELECT-then-INSERT

pg_advisory_xact_lock держит session-level эксклюзивную блокировку на время транзакции. Только одно соединение может держать блокировку для данного хеша в один момент.

Компромисс: hashtext 64-битный — коллизии возможны на масштабе (~10⁻¹⁰ при 10M ключей/день). Приемлемо для большинства нагрузок; security-критичные пути используют полный unique-индекс. Блокировка должна держаться на весь запрос включая внешние API-вызовы (десятки-сотни миллисекунд) — следи за pg_locks при инцидентах.

Масштабирование кеша: Redis Cluster

Один Postgres primary упирается примерно в 5–10к записей/сек на commodity-железе. На 50к req/сек idempotency-запись становится узким местом.

Redis Cluster с SETNX:

SETNX idempotency:{key} {fingerprint}:{status} EX {ttl_seconds}

SETNX атомарен: set-if-not-exists. Redis Cluster шардирует по hash ключа, распределяя нагрузку по нодам. Каждая нода тянет ~50–100к SETNX/сек.

Риск durability: Redis по умолчанию делает async fsync. Crash в течение миллисекунд после записи может потерять запись. Для платёжного API это означает: ключ пропал, следующий retry обрабатывается как новый — потенциальное двойное списание.

Двухуровневый кеш: production-паттерн

Платёжные API с юридической ответственностью за двойные списания используют гибрид:

1. Hot path: Redis — SETNX по ключу. Если успех (новый ключ) — обрабатывать и писать в Postgres асинхронно через outbox. Если конфликт (существующий ключ) — читать Redis для кешированного ответа.
2. Cold path: Postgres — авторитетная запись. Если Redis miss (редко, при crash) — провалиться в Postgres для восстановления авторитетного ответа.

Запрос → Redis SETNX
          ├─ Новый: обработать + записать в Postgres async + кешировать в Redis
          ├─ Конфликт: вернуть кешированный ответ из Redis
          └─ Redis miss: читать из Postgres → заполнить Redis → вернуть

Stripe и Square используют этот гибрид в production. Чистый Redis приемлем для нефинансовых нагрузок (регистрации, аналитические события), где редкий дубликат — шум в логах, а не compliance-событие.