Data engineering
Event sourcing: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажи или напиши полный ответ по памяти, прежде чем открыть модельный — усилие припоминания и закрепляет паттерн в голове, особенно те части, что кусаются в продакшене.
Восстанови хребет юнита — лог как истина, состояние как свёртка, projection CQRS, eventual consistency, snapshot и вечное версионирование — не подсматривая в урок.
- 01Какая одна инверсия определяет event sourcing и почему именно она источник всей пользы и всей цены?
- 02Коллега говорит «мы публикуем события в Kafka, значит мы event-sourced». Почему это может быть неверно и что реально сделало бы это event sourcing?
- 03Что такое CQRS в этом контексте, почему projection одноразовы и какие два свойства делают их безопасными в продакшене?
- 04Как обработать лаг read-модели в UI, не протекая архитектурой пользователю?
- 05Почему стоимость replay растёт неограниченно, как snapshot это чинят и в чём footgun snapshot?
- 06Почему версионирование схемы событий вечно, как его решает upcasting и как стирание по GDPR взаимодействует с неизменяемым логом?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: одна инверсия (append-only лог это истина, состояние это свёртка) покупает аудит, темпоральные запросы и replay, а счёт выставляет в версионировании, GDPR, snapshot и eventual consistency. Event sourcing это не топик Kafka, эмитированный после записи в БД; projection CQRS одноразовы, идемпотентны и eventually consistent; лаг это UX-проблема по экранам; snapshot ограничивают replay, но молча дрейфуют; версионирование вечно, поэтому делаешь upcast; а GDPR решается crypto-shredding с юридической оговоркой. Одно правило под всем этим: никогда не мутируй лог.