⚡️ Когда стоит применять паттерн Idempotent Consumer?

В распределённых системах всё непредсказуемо: сообщения могут прийти поздно, в неправильном порядке или продублироваться.
Если надеяться, что каждое сообщение обработается «строго один раз», рано или поздно появятся тихие ошибки в данных.

Производитель может частично решить проблему: многие брокеры (Azure Service Bus, Amazon SQS) сами отбрасывают дубликаты, если у сообщения есть уникальный MessageId.

Но у потребителя ответственность больше.
Паттерн Idempotent Consumer предотвращает повторные побочные эффекты:

1. Перед обработкой проверяем локальную таблицу с ключом (MessageId, ConsumerName).
2. Если записи нет - выполняем логику, коммитим транзакцию и записываем факт обработки.
3. Если запись уже есть - сообщение повторное, просто выходим.

Что делать с внешними сервисами?
Некоторые поддерживают idempotency key (например, email-сервисы), и тогда повторный запрос просто игнорируется.
Если сервис это не умеет, можно сохранять намерение локально и выполнять действие отдельным надёжным процессом.

Важно: не все обработчики нуждаются в этом паттерне.
Если операция сама по себе безопасна при повторе (обновить статус, пересобрать кэш) — дополнительные проверки не нужны.

Используйте Idempotent Consumer там, где повторное выполнение может привести к деньгам, ошибкам или сбоям в бизнес-логике.

milanjovanovic.tech/blog/the-idempotent-consumer-pattern-in-dotnet-and-why-you-need-it