Data engineering
Event sourcing: тест с множественным выбором
Суть Синтез по всему юниту event sourcing с множественным выбором — лог как источник истины, projection и CQRS, replay, snapshot, версионирование событий и GDPR поверх неизменяемого лога.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает решение, которое ты принимаешь, проектируя или эксплуатируя event-sourced систему — не определение для пересказа, а компромисс, который надо взвесить, когда лог это истина, а всё остальное производно.
Цель
Убедись, что можешь связать append-only лог, projection, replay, snapshot, версионирование и GDPR — синтез, к которому вёл урок, на той глубине, где решения реально кусаются.
Викторина
Completed
Коллега утверждает: «мы и так публикуем доменные события в Kafka после каждой записи в БД, значит мы event-sourced». Почему это, скорее всего, неверно?
Heads-up Эмиссия событий необходима, но недостаточна. Определяющее свойство — лог авторитетен и состояние выводится из него, а не то, что события публикуются побочным каналом после того, как база уже держит настоящую истину.
Heads-up Kafka может служить хранилищем событий с оговорками (бесконечный retention, без компакции). Изъян здесь в dual-write, где истину держит БД, а не в самой Kafka.
Heads-up Партиционирование — про порядок и пропускную способность, не про то, лог ли источник истины. Реальная проблема в том, что авторитетна закоммиченная строка, а не лог.
Викторина
Completed
Почему projection (read-модели) безопасно считать одноразовыми и что это даёт операционно?
Heads-up Одноразовость идёт от воспроизводимости через replay, а не от бэкапов. Бэкап восстанавливает старую форму; replay может построить совершенно новые формы, которых в бэкапе не было.
Heads-up Projection хранят производное состояние, а не авторитетные события. События живут в append-only хранилище; projection это одноразовая материализация из них.
Heads-up CQRS делает обратное — он позволяет свободно добавлять, удалять и пересобирать read-модели именно потому, что они производны и одноразовы.
Викторина
Completed
Пользователь жмёт «Сохранить», ты добавляешь событие, потом редиректишь на список из projection — и его изменения там нет. В чём корневая причина и правильный фикс?
Heads-up Заставлять projection обновляться синхронно с каждым append выбрасывает развязку и масштабируемость, ради которых существует CQRS, а событие не потеряно — оно просто ещё не спроецировано.
Heads-up Идемпотентность про безопасную повторную доставку того же события, а не про пропавшее. Изменения нет, потому что projection просто не догнала — лаг replay, а не дубль.
Heads-up At-most-once меняет риск дублей на риск потери событий, что здесь хуже. Append, вероятно, прошёл; read-модель просто отстаёт от него на некоторый лаг.
Викторина
Completed
Загрузка одного агрегата сворачивает 4 миллиона событий и слишком медленна. Ты добавляешь snapshot. От какого одного режима отказа защищается сеньор?
Heads-up Snapshot хранятся отдельно (snapshot-хранилище или боковой поток), а не мутацией событий. Это чистая оптимизация чтения, лог остаётся нетронутым.
Heads-up Snapshot — оптимизация поверх replay: читаешь snapshot на версии N, потом проигрываешь события после N. Полный replay с самого начала всегда доступен.
Heads-up Snapshot делаются периодически (каждые N событий или по расписанию); вся их ценность в амортизации стоимости свёртки, а не в захвате каждого события.
Викторина
Completed
OrderPlaced получает обязательное поле currency. У миллионов исторических OrderPlaced его нет. Каков стандартный подход?
Heads-up Мутация прошлых событий нарушает append-only инвариант, ломает каждый downstream replay и гарантию аудита, обесценивает конкурентность по версиям. Лог не переписывают.
Heads-up Удаление истории уничтожает аудит-трейл и темпоральные запросы, ради которых существует паттерн, и делает агрегаты несобираемыми. Upcasting сохраняет историю, показывая новую форму.
Heads-up Проверки на null навсегда протекают историей схемы в каждого потребителя. Upcasting централизует фикс в одной цепочке преобразований, и доменный код остаётся чистым.
Викторина
Completed
Пользователь реализует право на забвение по GDPR; его PII вшита в сотни неизменяемых событий. Что реально шипит сеньор?
Heads-up Переписывание append-only лога ломает каждый replay, уничтожает аудит-трейл и обесценивает версии оптимистичной конкурентности. Стоит мутировать историю — и у тебя уже не event sourcing.
Heads-up Дисковое шифрование защищает от физической кражи, а не от того, что система удерживает данные субъекта после запроса на удаление. Оно ничего не даёт для удаляемости данных одного человека.
Heads-up Это выбрасывает аудит, темпоральные запросы и replay для всего агрегата ради проблемы, которую crypto-shredding решает хирургически. Чрезмерная перекоррекция.
Итог
Сквозная линия юнита — одна инверсия и её следствия: append-only лог это источник истины, текущее состояние это свёртка, всё прочее производно. Projection это одноразовые read-модели, пересобираемые через replay, поэтому чтения eventually consistent. Snapshot ограничивают стоимость replay, но молча дрейфуют без защиты. Версионирование вечно — старые формы живут всегда, поэтому делаешь upcast, а не переписывание. А GDPR поверх неизменяемого лога решается crypto-shredding с реальной юридической оговоркой. Каждый ответ сводится к одному правилу: никогда не мутируй лог; выводи, проигрывай и преобразуй вокруг него.