Event sourcing
Тема дорожной карты · Software Architecture
Event Sourcing представляет собой архитектурный подход, при котором все изменения состояния системы сохраняются в виде последовательности событий. Это позволяет отслеживать полную историю изменений, что делает этот подход особенно ценным для систем, где важна полная история действий. Хранение событий в виде последовательности обеспечивает полную аудит-траекторию, что особенно важно в регулируемых и финансовых отраслях.
Event Sourcing обеспечивает важные преимущества, такие как возможность повторного воспроизведения событий для создания новых представлений данных и отладки через временной ряд. Однако, этот подход также имеет свои сложности, такие как сложность эволюции схемы событий и сложность эффективного запроса текущего состояния.
Как это работает
В Event Sourcing все изменения состояния системы записываются в виде событий. Эти события хранятся в виде последовательности, которая всегда увеличивается, но никогда не уменьшается. Текущее состояние системы можно получить, сворачивая все события, которые были созданы с момента начала работы системы. Сворачивание событий позволяет получить актуальное состояние системы.
Проекции (read models) представляют собой вычисляемые представления текущего состояния, которые создаются путем сворачивания событий. Для ответа на запрос, такой как "каков баланс?", можно либо свернуть все события (что является медленным процессом, но всегда актуальным), либо поддерживать обновляемую проекцию (что является быстрым, но добавляет сложность).
Replay является суперсилой Event Sourcing: когда требуется создать новый view исторических данных, можно не запрашивать базу данных, а воспроизвести все релевантные события через новую сворачивающую логику.
Когда применять
Event Sourcing особенно полезен в регулируемых и финансовых отраслях, где требуется полная аудит-траектория. Это подходящий выбор для систем, где важны сложные временные запросы, например, "каково было состояние в 15:00 прошлого вторника?". Кроме того, Event Sourcing подходит для систем, которым необходимо отвечать на несколько проекционных вопросов из тех же данных. Однако, для простых CRUD-приложений, где требуется только базовая создание, чтение, обновление и удаление данных, использование Event Sourcing может быть излишним и усложнить архитектуру системы.
Типичные ошибки
- Эволюция схемы событий — старые события могут быть записаны в старой схеме, что может создать проблемы для новых читателей событий. Это требует поддержания обратной совместимости для всех читателей событий на протяжении всего жизненного цикла системы.
- Performance cliffs — сворачивание миллионов событий для ответа на один запрос может быть очень медленным. Это требует поддержания обновляемых проекций, чтобы обеспечить быстрые ответы на запросы.
- 'Snapshots' как escape hatch — периодические снимки состояния могут улучшить производительность, но они могут также реинтродуцировать управление состоянием, подобное базе данных, что может усложнить архитектуру системы.