Sergey Pichkurov

Касательно 'Dual writes позволят эмитить уже "правильные" события сразу.', то тут можно только ответить цитатой из классики - "Догнать Савранского - это утопия". Есть сразу н...

> Sergey, я вот вообще не понял вопроса, что за реализация messaging на actors? При чем тут это, откуда это взялось? > В чем проблема синхронизации акторов с основной моделью?...

а конкретнее, почему возникает ошибка, разбирались ? возможная причина - несовместимое изменение формата результата, если так то это надо решать репроцессингом

Event Sourcing пришел из финтеха и gambling, кстати. С "реальным энтерпрайзом" основная проблема - это люди а не техника, тк энтерпрайз не любит всякие инновации (если обычно...

> 1) Хмм, вот у меня чистая бизнес-логика много-много больше 15-20 процентов. Где-то под 90 скорее. Что я делаю не так? ну, например - сравнить Дебит с Кредитом, или добавить...

мониторить кол-во produced сообщений в топик? > Можно ли быть уверенным, что если мне поступают сообщения из спец. топика с ожидаемой частотой, то и с целевыми топиком/партици...

Iосновной IMO пропозишен - это реактивный data plane. и это нечто больше чем просто реактивные стримы плюс материалайзерами. nosql БД - это здорово, но зачем шардировать воо...

так из-за чего, собственно, ошибка происходит? если первая исключение происходит в коде приложения, то его надо как-то обрабатывать самому

ну PR висит с апреля и, судя по комментам, его уже гоняют https://issues.apache.org/jira/browse/KAFKA-7500?focusedCommentId=16824791&page=com.atlassian.jira.plugin.system.issu...

именно так. но насколько это проблема? в большинстве случаев (как например, для платежной системы), внутри топика есть ключ (например accountId) и важно что бы сообщения гаран...

интересно, у нас 4 брокера по 12к партиций на каждом. нагрузка неравномерная (обычно низкая) но бывают и пики и там такого не замечалось. а какая версия кафки ?

> вот поэтому и делают "event log as a single source of truth", чтобы можно было полностью восстановить систему из него стоп, те *все* events  где-то лежат? и это конептульно ...

кто-то пользовался уже Mirror Maker 2.0 ? в-частности, мигрировал Kafka Streams приложения с одного кластера на другой без полного репроцессинга ?

> Упирался именно в число одновременных эффективных соединений с БД ... проще делать шардинг. там основные проблемы, по идее, возникают при горизонтальном масштабировании БД, ...

> чтобы можно было полностью восстановить систему из него вам приходилось сталкиваться с этим на практике? какие были объемы данных и параметры RTO ? (просто интересно)

для 3.2 я бы тоже выбрал ktable. одно непонятно - причем здесь транзакции ? какое они имееют отношение к slow storage ?

все-таки, в чем проблема что контексты будут видить есе events? это же только видеть? и при наличии avro перематить из одного формата в другой вообще не проблема ?

@szhem а какие параметры задачи? за что, конкретно, боремся? (у нас, например, тысячи партиций, если так подходить то никаких машин/дисков не хватит)

( безотносительно дискуссии на тему monolith vs microservices ) почему локальные проекции воспринимаются как возврат к монолиту ?

а какой смысл если авра есть из коробки ? придется пилить свой schema registry на protobuf, serialisers and all that stuff ....