Почему event sourcing в микросервисах — это бетонные сапоги для стартапа?

Ну давай разберем. Смотрю на очередной проект, где ребята с горящими глазами натянули event sourcing на три микросервиса, а через полгода у них база событий разрослась до 50 ГБ, и каждое чтение агрегата требует replay сотен тысяч ивентов. Они гордо называют это «гибкостью», а я называю это преждевременной оптимизацией с обратным эффектом. Ребята, вы уверены, что вам нужна полная история изменений, а не просто последнее состояние? Я не говорю, что event sourcing — зло. Для финтеха или аудита — да, там деваться некуда. Но для MVP или типового интернет-магазина это как вбивать гвозди микроскопом. Перечитайте «Building Evolutionary Architectures» — там четко: архитектура должна расти под нагрузку, а не под модные паттерны. Из практики: в половине случаев CQRS с простой projection-таблицей решает те же задачи без геморроя с идемпотентностью и консистентностью. Короче, мой циничный совет: прежде чем тащить event sourcing, задайте себе вопрос — вы точно готовы платить за это время разработки и инфраструктуру? Или это просто попытка сделать резюме покрасивее?