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

многоуровневый копролит

не уверен. дело в том, что у нас недавно была похожая боль, только в масштабах далеко не Волмарта. мы и на 100 ГБ данных-то в сумме не выйдем наверно за месяц, это если всю систему взять. но не суть, я к тому, что вопрос приоритезации потоков был одним из вопросов, которые я и поднял. и оказалось знаешь что, не поверишь - чтобы приоритезировать данные, как и чтобы выработать адекватную recovery strategy, нужно кристально четкое понимание того, какие потоки данных бизнесу нужны. это на 60% задача бизнес-аналитика, если не на 80%.

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

забавно. а для чего?

кто-то хочет почувствовать себя Всевышним?

просто так. потому что может

ну у нас был похожий процесс. ПМы и аналитики сказали "нам надо все. вообще все, навсегда и за все время"

аналитики от Бога

за год перепроигрывание событий я видел... аж ни разу

зато видел миллионы алертов в стиле "ваш консумер отстал на 5 сообщений"

а оно в техдизайн закладывается решения? отдельным пунктом?

возвращаясь к вопросу, почему разраб решил начать с начала стрима: не подумал, если коротко

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

связи между ними нет

потому что я давно замечаю, что вот эти все фишки они в коллективном бессознательном на уровне генетической памяти. "что-то такое читал на Хабре в перерывах между Сашей Грей не на Хабре" - обычно это так. не более, чем это.

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

снапшоты не?

ну у нас вроде бы читают целенаправленно. но как они делают выводы из прочитанного - хз, загадка для науки

снапшот == невозможность переиграть ВСЕ события, т.к. часть схлопнулись в снашот.