System Design
Event Sourcing & CQRS
Event Sourcing: основы
**Event Sourcing - хранение изменений, а не состояния** Традиционный подход: храним текущее состояние объекта Event Sourcing: храним последовательность событий, которые привели к этому состоянию Аналогия: - БД = фото (текущий снимок) - Event Store = видео (полная история)
**Ключевые принципы Event Sourcing:** 1. **Events are immutable** - события нельзя изменять/удалять 2. **Events are the source of truth** - БД вторична 3. **State is derived** - текущее состояние = replay всех событий 4. **Append-only** - только добавление новых событий
**Преимущества Event Sourcing:** | Преимущество
| **Полный аудит** | Каждое изменение записано навсегда | | **Time travel** | Можно восстановить состояние на любой момент | | **Debug** | Replay событий для воспроизведения багов | | **Analytics** | Полная история для ML/BI | | **Event-driven** | Естественная интеграция с микросервисами |
Что вы узнали о Event Sourcing: основы?
Event Store
**Event Store - специализированное хранилище событий** Требования: - Append-only writes - Ordered reads per aggregate - Optimistic concurrency control - High write throughput Варианты: EventStoreDB, Kafka, PostgreSQL, DynamoDB
**Optimistic Concurrency - защита от конфликтов**
При конфликте: reload aggregate, retry command
**Snapshotting - оптимизация загрузки** Проблема: aggregate с 10,000 событий - долго replay Решение: периодически сохранять snapshot состояния
Что вы узнали о Event Store?
Projections
**Projections - read models из событий** Проблема Event Sourcing: чтобы узнать "все заказы клиента" нужно: - Загрузить ВСЕ события - Отфильтровать по customer - Это медленно! Решение: Projections - предвычисленные view из событий
**Projection Handler:**
**Checkpoint - отслеживание позиции**
Что вы узнали о Projections?
CQRS Pattern
**CQRS - Command Query Responsibility Segregation** Разделение моделей: - **Command Model** (Write) - обрабатывает команды, генерирует события - **Query Model** (Read) - оптимизирована для чтения CQRS часто используется вместе с Event Sourcing, но они независимы!
**CQRS БЕЗ Event Sourcing:**
Можно использовать: - Read replicas PostgreSQL - Materialized views - Elasticsearch для поиска - Redis для кеширования
**Eventual Consistency в CQRS** Проблема: между записью и обновлением read model есть задержка
Решения: 1. **Read-your-writes** - после записи читать из write model 2. **Polling** - UI периодически обновляется 3. **WebSocket** - push когда projection updated 4. **Version в response** - UI ждёт нужную версию
Что вы узнали о CQRS Pattern?
Trade-offs и когда использовать
**Когда использовать Event Sourcing:** ✅ Подходит: - Финансовые системы (аудит, compliance) - Системы с complex domain logic - Нужен полный audit trail - Temporal queries ("состояние на дату X") - Event-driven architecture ❌ НЕ подходит: - Простые CRUD приложения - Частые updates одних данных (много событий) - Нужны сложные ad-hoc запросы к текущему состоянию - Команда не знакома с паттерном
**Сравнение подходов:** | Аспект | CRUD
| **Сложность** | Простой | Высокая | | **Аудит** | Нужен отдельно | Встроен | | **Масштабирование** | Средне | Отлично | | **Консистентность** | Strong | Eventual | | **Time travel** | Невозможно | Встроено | | **Debugging** | Просто | Replay событий | | **Schema changes** | Migration | Event versioning |
Что вы узнали о Trade-offs и когда использовать?