Comments 4
У нас CQRS, поэтому read side eventually consistent.
смотря какой performance, смотря какая delay
Спасибо за статью!
Про идемпотентность консьюмера через inbox по event_id - да, нужная защита от at-least-once.
На практике я видел ловушку уровнем выше и стоит она дорого: event_id спасает от повторной доставки одного и того же события, но не от двух разных событий с одним бизнес-намерением. Клиент ретраит по таймауту, на write-стороне рождается новый event_id - и inbox честно пропускает его как новый потому что по id он и правда новый. Лечили дедупом ещё и по ключу намерения операции, а не только по id события. По сути это как две идемпотентности на разных слоях: техническая по event_id у консьюмера и смысловая по ключу намерения на входе команды.
У меня в проекте похожая схема. В проекте с read-model есть ручки для изменения сущностей write-model-и. При формировании http запроса на него нашлепывается operation-id в хедере. Этот же id пишется в хедер кафки. Пока сервис с read-model-и не обработал event с таким operation-id, он не отдаст ответ на запрос. Ну еще подкостылили ожидание в 2 секунды, если уж совсем долго ивент идет или обрабатывается. Пока по башке не получили за такое решение, вроде работает)
Две базы: одна пишет, другая читает. CQRS без культа и с последствиями