Consumer-side dedup: самый дешёвый путь к exactly-once processing

Ты добавил dedup-проверку в payment consumer — быстрый SELECT перед списанием. Дубликаты упали с десятков в неделю до нуля. Потом, три недели спустя, истощение пула DB-коннекций вызвало тихий сбой проверки, и списание прошло дважды снова. Проверка была вне транзакции. Одна строка не в том месте.

Наивный dedup-паттерн и почему он не работает

Первый инстинкт — двухшаговая проверка:

SELECT 1 FROM processed WHERE msg_id = 'msg-7a3f';
-- если найдено: пропустить
-- если нет: вызвать Stripe, потом INSERT в processed

Это ломается при конкурентной доставке. Два consumer-а получают одно сообщение одновременно (возможно при rebalance или после visibility timeout). Оба делают SELECT в один момент, оба видят «не найдено», оба вызывают Stripe. Race condition. Два списания.

Правильный паттерн: INSERT первым, одна транзакция

Фикс: dedup INSERT и side effect в одной атомарной DB-транзакции, и INSERT первым:

BEGIN;
  INSERT INTO processed (msg_id, created_at)
  VALUES ('msg-7a3f', now());
  -- при UNIQUE violation: ROLLBACK и пропустить
  -- если insert успешен: выполнить side effect
  UPDATE orders SET status = 'paid' WHERE id = 'O-123';
COMMIT;

При unique-constraint violation транзакция откатывается — side effect никогда не выполняется. При commit обе записи — dedup-row и side effect — пишутся вместе. Нет crash-окна между ними.

Ключевое свойство: если consumer падает после commit DB-транзакции, но до ack брокера, брокер передоставляет. Следующий consumer пытается INSERT msg-7a3f снова, попадает на unique constraint, откатывается, ack-ит брокер. Side effect уже был выполнен один раз; дубликат тихо отбрасывается.

Внешние API: Stripe Idempotency-Key

Трюк с транзакцией работает только когда side effect — DB-запись внутри той же транзакции. А внешние API — Stripe, SES, Twilio? HTTP-вызов нельзя включить в Postgres-транзакцию.

Паттерн для внешних API: передавай Idempotency-Key header, derived из msg ID.

POST /v1/charges
Idempotency-Key: msg-7a3f

Stripe хранит ключ и первый response 24 часа. Если вызвать Stripe снова с тем же ключом (потому что брокер передоставил), Stripe возвращает кешированный response без повторного списания. PayPal, Square и большинство payment API следуют той же конвенции.

Когда внешний API поддерживает idempotency keys, паттерн:

1. INSERT pending-строку: INSERT INTO stripe_intents (msg_id, status='pending') — в транзакции. Это intent-лог.
2. Вызвать внешний API с Idempotency-Key = msg_id.
3. При успехе: UPDATE строку в status='completed', charge_id=....

Если consumer падает между шагами 2 и 3, redelivery снова вызывает Stripe с тем же ключом (Stripe возвращает кешированный charge_id), потом завершает UPDATE. Двойного списания нет.