Я прочитал этот хороший пост от Джонатана Оливера о том, как обрабатывать события, вышедшие из строя.

http://blog.jonathanoliver.com/cqrs-out-of-sequence-messages-and-read-models/

Решение, которое мы используем, состоит в том, чтобы удалить сообщение из очереди и поместить его в «таблицу хранения», пока не будут получены все сообщения с предыдущей последовательностью. Когда все предыдущие сообщения были получены, мы вынимаем все сообщения из таблицы хранения и последовательно запускаем их через соответствующие обработчики. Как только все обработчики были выполнены успешно, мы удаляем сообщения из таблицы хранения и фиксируем обновления для прочитанных моделей.

Это работает для нас, потому что домен публикует события и помечает их соответствующим порядковым номером. Без этого решение, представленное ниже, было бы намного сложнее, если не невозможно.

Это решение использует реляционную базу данных в качестве механизма постоянного хранения, но мы не используем ни один из реляционных аспектов механизма хранения. В то же время во всем этом есть предостережение. Если сообщения 2, 3 и 4 приходят, но сообщение 1 никогда не поступает, мы не применяем их. Сценарий должен происходить только в том случае, если имеется сообщение об ошибке обработки 1 или сообщение 1 каким-то образом теряется. К счастью, достаточно легко исправить любые ошибки в наших обработчиках сообщений и перезапустить сообщения. Или, в случае утерянного сообщения, перестроить модели чтения из хранилища событий напрямую.

Есть несколько вопросов, особенно о том, как он говорит, что мы всегда можем спросить магазин событий о пропущенных событиях.

Должна ли сторона записи CQRS предоставлять сервис стороне чтения для «воспроизведения» воспроизведения событий? Например, если событие 1 не было получено, но есть 2, 4, 3, можем ли мы попросить хранилище событий через службу переиздать события, начиная с 1?Является ли этот сервис ответственным за запись в CQRS?Как нам перестроить модель чтения, используя это?