Спасибо за комментарий. В нашей реализации inbox используется событийная модель. Т.е. берется из inbox -> в транзакции выполняется бизнес операция и изменение статуса у сообщения. Сама статья больше сфокусирована на том, что Apache Kafka не даёт гарантии доставки на уровне всей системы и где именно эти гарантии теряются. Если будет интересно, могу отдельно разобрать реализацию Outbox/Inbox с учётом идемпотентности и границ транзакций.
Идемпотентный продюсер решает только одну задачу — предотвращает дублирование записей в Kafka при повторной отправке. Он гарантирует, что одно и то же сообщение не будет записано в топик дважды, даже если продюсер повторно отправит его из-за сетевого сбоя. Это работает только внутри Kafka.
Идемпотентный продюсер не решает проблему согласованности между бизнес-операцией и публикацией события: если сервис успел сохранить заказ в БД, но упал до отправки сообщения в брокер — событие потеряется, и другие сервисы об этом заказе не узнают.
Спасибо за комментарий. В нашей реализации inbox используется событийная модель. Т.е. берется из inbox -> в транзакции выполняется бизнес операция и изменение статуса у сообщения.
Сама статья больше сфокусирована на том, что Apache Kafka не даёт гарантии доставки на уровне всей системы и где именно эти гарантии теряются.
Если будет интересно, могу отдельно разобрать реализацию Outbox/Inbox с учётом идемпотентности и границ транзакций.
Идемпотентный продюсер решает только одну задачу — предотвращает дублирование записей в Kafka при повторной отправке.
Он гарантирует, что одно и то же сообщение не будет записано в топик дважды, даже если продюсер повторно отправит его из-за сетевого сбоя. Это работает только внутри Kafka.
Идемпотентный продюсер не решает проблему согласованности между бизнес-операцией и публикацией события:
если сервис успел сохранить заказ в БД, но упал до отправки сообщения в брокер — событие потеряется, и другие сервисы об этом заказе не узнают.