Две базы: одна пишет, другая читает. CQRS без культа и с последствиями

[Hramoff]

У нас CQRS, поэтому read side eventually consistent.

смотря какой performance, смотря какая delay

[NiQkrya]

Спасибо за статью!

[vsinyavsky]

Про идемпотентность консьюмера через inbox по event_id - да, нужная защита от at-least-once.

На практике я видел ловушку уровнем выше и стоит она дорого: event_id спасает от повторной доставки одного и того же события, но не от двух разных событий с одним бизнес-намерением. Клиент ретраит по таймауту, на write-стороне рождается новый event_id - и inbox честно пропускает его как новый потому что по id он и правда новый. Лечили дедупом ещё и по ключу намерения операции, а не только по id события. По сути это как две идемпотентности на разных слоях: техническая по event_id у консьюмера и смысловая по ключу намерения на входе команды.