под конкретный поток данных (например, отдельный топик для передачи данных о товарах, отдельный топик для цен для товаров и т.п.);
- писать все в один топик, добавляя в сообщение информацию для маршрутизации и дальше забирать из топика, обрабатывая полученное сообщение, согласно информации о маршрутизации?
Когда обязательно использование общего топика - необходимо строго упорядочить разные события Когда нельзя - требуется авторизация при чтении конкретного типа сообщения, а не групп сообщений В остальных случаях трейдофы между менеджментом большого количества сущностей-топиков, их связыванием со схемами и типами событий, разграничения потоков по нагрузке, группировке по потребительским сервисам и т.п. Основное на что смотреть - как много лишних данных будет читать консумер, если незначительно то ок, если большой процент скипать, то стоит выделить такие события в отдельный топик и снять доп нагрузку с сервиса, который будет просто впустую читать сообщения и откидывать их
спасибо большое!
Как правило, это само собой получается в процессе анализа, какие агрегаты и bounded contexts какие сообщения публикуют, насколько "полные" вы планируете сообщения и насколько там принципиален порядок. Проведите Event Storming например! Что подразумевается под маршрутизацией я даже боюсь пытаться угадывать, но считайте что ваши сообщения - броадкаст. Если смотреть на пример "товары" (видимо описания) и "цены на товары" - это, очевидно, отдельные контексты и меняются они независимо (надеюсь), как и складские остатки по данным товарам, и очевидно что это разные топики. Но, вероятно, все сообщения об изменении описаний и характеристик товаров логично держать в одном топике, потому что порядок (для каждой конкретной сущности) имеет значение (NB! задумайтесь о ключе партиционирования - верноятно, это типа `articleUuid`)
Обсуждают сегодня