Idempotent consumers

Идемпотентный consumer даёт один и тот же результат при однократной или многократной обработке. Техники: естественные уникальные ключи (order ID), таблицы обработанных сообщений с окном дедупликации, compare-and-set по версии и outbox, связывающий публикацию с commit в БД.

Проектируйте идемпотентность на уровне бизнес-операции, а не только транспорта. Handler, дважды списавший карту, неверен даже при exactly-once на брокере. Храните достаточно состояния, чтобы обнаруживать replay в окне redelivery.

На интервью: спроектируйте идемпотентность для `PaymentCaptured`, сравните dedup-таблицу и unique constraint и объясните связь с at-least-once брокерами.

Типовые ошибки: ключи идемпотентности истекают раньше max redelivery; гонка параллельных consumer на одном ключе; побочные эффекты вне транзакции; вера, что offset Kafka гарантирует бизнес-идемпотентность.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

• Определите естественный ключ идемпотентности.
• Сохраняйте результат обработки до ack.
• Покройте внешние эффекты outbox или компенсациями.
• Явно тестируйте дубликаты доставки.