Опишите концепцию Idempotency Receiver при обработке сообщений из брокера. Если брокер гарантирует доставку at-least-once, как на стороне бэкенда спроектировать слой дедупликации, учитывая, что два абсолютно идентичных сообщения могут прийти в воркер с разницей в миллисекунду?

Idempotent Receiver связывает сообщение с устойчивым event_id и атомарно фиксирует дедупликацию вместе с бизнес-изменением. Проверка «сначала SELECT, потом INSERT» без ограничения уникальности небезопасна.

Создайте таблицу обработанных событий с уникальным (consumer, event_id). В одной транзакции попытайтесь вставить ID и выполнить эффект; конкурентный дубль упрётся в уникальность, а не пройдёт параллельно. При rollback запись дедупликации тоже откатывается, позволяя безопасный повтор. Ack брокеру отправляют после commit. Сравнение одинакового текста недостаточно: два разных события могут иметь равный payload. Для внешнего эффекта используйте его idempotency key или outbox; срок хранения ID должен покрывать допустимый replay.