Why Event Sourced Systems Fail [eng] / Greg Young

Конспект доповіді Грега Янга «Why Event Source Systems Fail»

1. Тема та контекст

• Тема: Аналіз причин невдач проектів, побудованих на основі Event Sourcing.
• Контекст: Доповідь на конференції fwdays. Спікер — Грег Янг, незалежний консультант, підприємець, один із засновників термінів CQRS (Command Query Responsibility Segregation) та Event Sourcing. Має понад 15 років досвіду в комп’ютерних науках.
• Формат: Класична доповідь (45-50 хв) з подальшою сесією питань та відповідей.

2. Ключові тези

• Основна мета — обговорити недоліки та проблеми Event Sourcing, про які часто мовчать, а не технічні деталі його реалізації.
• Головна ідея: Більшість невдач проектів на Event Sourcing не є вадою самої концепції, а випливають з людського фактору та недосвіду команди.
• Спікер розглядає чотири основні скарги на Event Sourcing:
  1. "Воно інше": Це правда, і потрібен час, щоб звикнути до нових патернів.
  2. "Версіонування важке": Це справжня та серйозна проблема, яку не можна ігнорувати.
  3. "Моделювання інше": Це не недолік, а просто інший підхід, який для певних проблем може бути кращим.
  4. "Eventual Consistency — це погано": Найпоширеніша та найспірніша скарга. Насправді eventual consistency часто є свідомим архітектурним вибором для досягнення гнучкості, масштабованості та георозподілу, а не вимушеним злом.

3. Технічні деталі

• Event Sourcing (коротко): Замість зберігання поточного стану даних (наприклад, замовлення в БД) система зберігає журнал подій (append-only log), які призвели до цього стану (наприклад, "кошик створено", "товар X додано"). Кінцевий стан відтворюється шляхом відтворення (replay) цих подій. Видалення даних також є подією (наприклад, "товар X видалено").
• Проблема версіонування: Події зберігаються назавжди, а їхня структура (схема) може змінюватися з часом. Як читати старі події в новій системі?
  • Рішення: Використання слабких схем (weak schema), де можна лише додавати/видаляти поля, але не перейменовувати. Більш радикальне рішення — трансформація всіх подій при кожному релізі, коли старі події автоматично конвертуються у новий формат і записуються в нове сховище.
• Eventual Consistency та CQRS: Спікер підкреслює, що Event Sourcing та CQRS — це різні концепції, які часто використовуються разом.
  • Eventual consistency виникає, коли write model (де записуються події) та read model (де дані трансформуються для читання) оновлюються не в одній транзакції.
  • Причина такого вибору: Можливість мати багато read models різних типів (SQL, документні БД, full-text search тощо) та географічно розподіляти їх по всьому світу для локальної продуктивності.
• Технічне рішення для "приховування" eventual consistency:
  1. Після успішного запису події в event store клієнту повертається версія/позиція цієї події в лозі.
  2. При наступному запиті до read model клієнт передає цю версію.
  3. Read model знає, до якої версії він уже обробив події. Якщо його версія нижча за запитану, він може повернути відповідь "retry-after" (повторити через X секунд) або показати проміжний стан.
  • Це проста реалізація, яка може бути додана до існуючої системи за кілька годин.

4. Практичні поради

• Не поспішайте: Перший проект на Event Sourcing буде складнішим — це нормально. Потрібен час, щоб набути досвіду саме в цій парадигмі.
• План версіонування з самого початку: Не ігноруйте проблему версіонування подій. Оберіть стратегію (слабкі схеми, трансформація) на ранніх етапах та, бажано, з допомогою досвідченого архітектора.
• Мисліть про багато read models: Якщо у вашій архітектурі лише один read model, ви, ймовірно, не отримуєте ключових переваг CQRS/Event Sourcing. Подумайте про різні способи представлення даних для різних цілей (звіти, пошук, API).
• Eventual consistency — це інструмент, а не вирок: Її можна технічно "приховати" від кінцевого користувача за допомогою механізму з версіями та повторними спробами.
• Питання "навіщо?": Впроваджуйте Event Sourcing тоді, коли для цього є реальна бізнес-потреба (повний аудит, регуляторні вимоги, складні часові зрізи даних, необхідність георозподілу), а не лише тому, що це "крута" технологія.

5. Дискусійні моменти

• Під час Q&A обговорювалося, чи можуть фреймворки вирішити всі проблеми Event Sourcing/CQRS за розробників.
  • Позиція Грега Янга: Багато проблем (як-от аналіз доменної області, моделювання) — це питання мислення, а не коду, тому фреймворк не вирішить їх. Прості технічні рішення (як для eventual consistency) не потребують складних фреймворків.
  • Позиція учасника дискусії (Діми): Можливо, індустрії не вистачає готових інструментів або фреймворків, які б стандартизували вирішення типових проблем (як eventual consistency), запобігаючи помилкам через необізнаність. Проводиться аналогія з розвитком інструментів для машинного навчання.
• Чи завжди Event Sourcing/CQRS — це хороший вибір? Спікер категорично стверджує — ні. Це інструмент для певних цілей. Прийняття рішення має ґрунтуватися на конкретних бізнес-вимогах та досвіді команди, а не на моді. Наводиться приклад великого маркетплейсу (Olyox), де перехід на CQRS зазнав невдачі, що, на думку спікера, було проблемою людей (брак знань), а не технології.