Как спроектировать систему с гарантированной доставкой событий, согласованием транзакций и защитой от дублей?

Используйте transactional outbox на стороне отправителя и идемпотентный inbox/бизнес-ключ у получателя. Реалистичная база — повторяемая доставка с однократным эффектом.

В одной DB-транзакции сохраните бизнес-изменение и outbox-запись. Relay публикует её с устойчивым event-id, подтверждает доставку и безопасно повторяет после сбоя. Consumer в одной транзакции проверяет inbox/unique-key, выполняет изменение и отмечает обработку; offset подтверждается после commit. Для внешнего неатомарного эффекта нужен idempotency key или reconciliation. Добавьте retries, DLT и мониторинг зависших событий. Гарантии формулируйте при доступном устойчивом хранилище и восстановлении сервисов, а не как магическое отсутствие любых потерь.