Comments 6
Я люблю CQRS. В нашем легаси, как один из шагов в сторону мискросервисов, DDD, евентов + трушный CQRS, мы используем CDC. В нашем случае это Mongo + Kafka connector. И сабскрайберы подписываются на изменения определенных коллекций, и уже создают у себя нуные им вьюшки, в подходящщей базе данных и в подходящей структуре.
Тьфу тьфу работает стабильно и позволяет сделать анкаплинг сервисов и получить реальный профит.
Но нужно заранее думать о том как делать рикавери если что-то пошло не так. И если все делать правильно - рикавери сводится к рисету оффсета сабскрайбера на топик.
CDC делаете через Debezium?
Как решаете ситуацию когда мастер-базу восстанавливаете из бекапа?
На сколько я знаю, мы делаем не через дебезиум, а через стандартный коннектор - https://docs.mongodb.com/kafka-connector/current/
Этим уже девопсы занимаютсяу нас.
Насчет восстановления базы - интересный вопрос. Вряд ли тут есть генерное решение. Но в принципе можно к этому относиться как частному случаю ресета оффсета опредееленного консьюмера.
Если сама синхронизация очень тупая, в виде простых идемпотентных апсертов на стороне сабскрайберов, то все должно работать out of the box.
Если же вьюшки строятся сложнее (например мерж нескольких стримов или обогащение евентов синхронно (что не очень хорошо) в консьюмере, тут уже нужно конкретно по ситуации смотреть. Возможно что-то умнее придумать при помощи idempotencyId, timestamps, маппинга оффсета на стороне сабскрайбера с данными чтобы и написание умного рикавери процесса.
Есть конечно нюансы. Например в нашем случае используются топики, где храняться несколько месседжей на определенный _id (зависит от настроек топика кафки) и нужно иметь ввиду что когда будет идти восстановление, то в какой-то промежуток времени мы можем иметь во вьюшке не самые последние данные из тех что мы имеем.
Насколько я знаю, можно настроить топик хранить только последнюю копию документа монги.
Извините, но перевод ужасный. Не смог читать дальше 3 абзаца.
Преодоление сложности в CQRS