Патерн Event sourcing та його застосування
У статті розглядається застосування патерну Event sourcing у програмуванні розподілених систем, які потребують надійного збереження історії змін і забезпечення високої відмовостійкості. Описано теоретичні основи патерну, його архітектуру та ключові компоненти, а також проведено порівняння з іншими п...
Saved in:
| Published in: | Проблеми керування та інформатики |
|---|---|
| Date: | 2025 |
| Main Authors: | , |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
Інститут кібернетики ім. В.М. Глушкова НАН України
2025
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/211403 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Патерн Event sourcing та його застосування / А.М.Глибовець, І.С.Янкін // Проблемы управления и информатики. — 2025. — № 3. — С. 74-84. — Бібліогр.: 13 назв. — укр. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859799674481803264 |
|---|---|
| author | Глибовець, А.М. Янкін, І.С. |
| author_facet | Глибовець, А.М. Янкін, І.С. |
| citation_txt | Патерн Event sourcing та його застосування / А.М.Глибовець, І.С.Янкін // Проблемы управления и информатики. — 2025. — № 3. — С. 74-84. — Бібліогр.: 13 назв. — укр. |
| collection | DSpace DC |
| container_title | Проблеми керування та інформатики |
| description | У статті розглядається застосування патерну Event sourcing у програмуванні розподілених систем, які потребують надійного збереження історії змін і забезпечення високої відмовостійкості. Описано теоретичні основи патерну, його архітектуру та ключові компоненти, а також проведено порівняння з іншими підходами щодо розробки складних програмних систем.
The article discusses Event sourcing pattern that used in programming distributed systems that require reliable storage of change history and high fault tolerance. It describes the theoretical foundations of the pattern, its architecture, and key components, as well as compares it with other approaches to developing complex software systems.
|
| first_indexed | 2026-03-16T06:39:43Z |
| format | Article |
| fulltext |
© А.М. ГЛИБОВЕЦЬ, І.С. ЯНКІН, 2025
74 ISSN 2786-6491
УДК 004.42
А.М. Глибовець, І.С. Янкін
ПАТЕРН EVENT SOURCING
ТА ЙОГО ЗАСТОСУВАННЯ
Глибовець Андрій Миколайович
Національний університет «Києво-Могилянська академія», м. Київ,
https://orcid.org/0000-0003-4282-481X
a.glybovets@ukma.edu.ua
Янкін Ігор Сергійович
Національний університет «Києво-Могилянська академія», м. Київ,
ihor.yankin@ukma.edu.ua
У статті розглядається застосування патерну Event sourcing у програ-
муванні розподілених систем, які потребують надійного збереження
історії змін і забезпечення високої відмовостійкості. Описано теоретичні ос-
нови патерну, його архітектуру та ключові компоненти, а також прове-
дено порівняння з іншими підходами щодо розробки складних програм-
них систем. Патерн Event sourcing забезпечує збереження стану систе-
ми через послідовність подій, внаслідок чого можна ефективно
відновлювати попередні стани та підтримувати надійність у масштабо-
ваних рішеннях. Зокрема аналізується використання цього підходу
у таких компаніях, як Netflix, що гарантує високу відмовостійкість і
масштабованість їхньої платформи для завантаження контенту. Підкрес-
лено необхідність розвитку нових фреймворків для спрощення імпле-
ментації патерну в різних мовах програмування, таких як .NET, Python,
Elixir, Java тощо. Зазначено, що більшість наявних рішень має обмеже-
ну інтеграцію з базами даних і не підтримує асинхронну обробку подій,
що звужує їх застосування у системах з певними вимогами. Особливу
увагу приділено викликам, що виникають при використанні Event
sourcing, таким як необхідність збереження великої кількості подій (що
може збільшити обсяг даних) та неможливість редагування минулих
записів. Наголошено на важливості оцінки переваг і недоліків у засто-
суванні патерну перед його впровадженням у реальні проєкти. Патерн
добре поєднується з іншими архітектурними практиками, такими як
CQRS (Command Query Responsibility Segregation) та DDD (Domain-
Driven Design), і може бути використаний для оптимізації керування дани-
ми та бізнес-процесами у складних програмних рішеннях. Результатом
дослідження є комплексний аналіз використання патерну для реалізації
ефективної роботи з подіями в програмних проєктах, що дає змогу знач-
но підвищити якість, надійність, гнучкість та масштабованість розроб-
люваного програмного забезпечення.
Ключові слова: застосунок, архітектура програмних систем, патерни про-
грамування, асинхронність, надійність, масштабованість, подія.
Вступ
Програмування розподілених систем, які потребують надійного збере-
ження історії змін та забезпечення високої відмовостійкості, вимагає ефектив-
них підходів до прийняття архітектурних рішень. У цьому контексті патерн
Event sourcing (подієве зберігання), що дає змогу зберігати всю історію змін
стану застосунків у вигляді подій, відкриває нові можливості для створення
програмного забезпечення [1]. У зв’язку з впровадженням сучасних архітектурних
mailto:a.glybovets@ukma.edu.ua
mailto:ihor.yankin@ukma.edu.ua
Міжнародний науково-технічний журнал
Проблеми керування та інформатики, 2025, № 3 75
практик і технологій для підвищення ефективності та надійності розроблюва-
них систем [2] є актуальним застосування цього патерну при реалізації складних
програмних проєктів асинхронного типу багатьма мовами програмування.
У статті описано використання патерну Event sourcing, детально проаналі-
зовано його теоретичне підґрунтя та можливу реалізацію. Значна увага приділя-
ється особливостям архітектури та ключовим компонентам, а також порівнянню
зі схожими рішеннями при розробці складних розподілених програмних систем.
Результатом дослідження є комплексний аналіз застосування патерну для реалі-
зації ефективної роботи з подіями в програмних проєктах, що значно підвищує
якість та надійність розроблюваного програмного забезпечення.
Патерн Event sourcing являє собою методологію збереження стану системи за
допомогою фіксації послідовності подій, які змінюють його. Головна увага приді-
ляється аналізу наявних інструментів, технік і фреймворків, які підтримують ефек-
тивну реалізацію цього патерну, а також розробці нових рішень, що значно по-
ліпшує та спрощує використання патерну в широкому спектрі побудови програм-
них проєктів.
Патерн Event sourcing
Наразі спостерігається тенденція до збільшення обсягів даних, якими оперує
програмне забезпечення [3]. Це обумовлено низкою факторів, серед яких — збіль-
шення генерації даних, а також зростання потреби в їх автоматичному зборі та
аналізі для прийняття рішень у різних галузях. Унаслідок цього не лише з’являються
нові переваги та можливості, але й постає питання щодо необхідності контролю і
збереження цих даних для подальшої роботи з ними.
Можливість вільно працювати з великими обсягами даних стає важливим
завданням для компаній і розробників. Один з напрямків роботи — вдосконален-
ня аудиту даних, зокрема відновлення стану системи на будь-який момент часу.
Це спрощує розробку програмного забезпечення і процес пошуку помилок та є
необхідним критерієм щодо відповідності регуляторним вимогам.
Саме вирішення цієї проблеми і пропонує Мартін Фаулер у своїй статті, де опи-
сується концепт патерну Event sourcing та наводиться приклад його реалізації [1].
В абстрактному розумінні патерн являє собою спосіб взаємодії зі сховищем
даних, коли можна зберігати та відновлювати дані про стан системи у певний мо-
мент часу. Це досягається внаслідок того, що будь-яка зміна стану системи збері-
гається як атомарна і незмінна подія, а сам стан реконструюється за допомогою
використання подій у тій послідовності, в якій вони відбувалися.
Хоча цей патерн можна застосувати окремо від усіх інших, але за спостереження-
ми експертів більшість розробників надають перевагу його інтеграції з іншими патер-
нами та підходами до дизайну систем [4]. Це пояснюється тим, що поєднання Event
sourcing з DDD (Domain-Driven Design — предметно-орієнтоване проєктування),
EDA (Event-Driven Architecture — подієво-орієнтована архітектура) та CQRS (Com-
mand Query Responsibility Segregation — розподілення відповідальності за команди та
запити) дає змогу досягти синергії, що значно покращує розробку та підтримку склад-
них систем і керування ними, роблячи їх більш гнучкими та масштабованими.
Підхід DDD до моделювання складного об’єктно-орієнтованого програм-
ного забезпечення зорієнтовано на предметну область бізнесу та правила йо-
го роботи. Event sourcing природно інтегрується з DDD, оскільки ефективно
фіксує всі зміни в доменних об’єктах як послідовність подій. На рис. 1 [5]
продемонстровано приклад такої інтеграції, де агрегатний корінь за запитом
користувача генерує певні зміни у вигляді подій, що потім передаються
76 ISSN 2786-6491
PaymentSettlement
PaymentCore
Bounded context Domain event Command
Aggregate Aggregate root
PaymentRoot PaymentPaidEvent
PaymentPayCommand
EventBus
PaymentFusion
User
Payment
у систему керування подіями, яка зберігає їх. Це не лише сприяє кращому
розумінню бізнес-процесів та їх еволюції в часі, але й уможливлює точне від-
творення стану домену на будь-який момент часу, що є важливим для DDD.
Рис. 1
Шаблон архітектури програмного забезпечення EDA фокусується на
створенні, «споживанні» подій та реагуванні на них. Event sourcing добре впи-
сується в EDA, оскільки події є головним елементом обох концепцій. Викорис-
тання Event sourcing у контексті EDA дає змогу зберігати історію змін у формі
подій, що можуть застосовуватися для асинхронної комунікації між різними
частинами системи, підвищення масштабованості та забезпечення більшої
гнучкості щодо відповідей на події. На рис. 2 [6] наведено приклад інтеграції
Event sourcing з EDA. На відміну від звичайного застосування EDA, у цьому
разі події не лише використовуються для сповіщення системи про зміни, але й
зберігаються відповідно до патерну Event sourcing, унаслідок чого надалі стає
можливим їх застосування для аудиту і відновлення станів іншими компонен-
тами системи.
Патерн CQRS розділяє операції читання та запису даних на дві окремі моделі,
щоб оптимізувати їх для відповідних операцій. Комбінація Event sourcing з CQRS
дає змогу побудувати потужну, хоч і просту, архітектуру (рис. 3 [7]), де події, що
відображають зміни стану, можна використати для асинхронного оновлення мо-
делей читання і тим самим забезпечити високу продуктивність та консистентність
даних. Такий підхід дає змогу ефективно масштабувати систему та оптимізувати
відповіді на запити користувачів.
Застосування патерну Event sourcing передбачає збереження всіх змін станів
об’єктів та системи як послідовності подій, на відміну від більш звичного збере-
ження лише останнього стану сутності. Кожна подія описує зміну, яка сталася,
і містить достатньо інформації для того, щоб можна було відтворити цю зміну.
Як сутність розуміємо об’єкт доменної моделі, який має сталу ідентичність у часі
та такі ключові ознаки: унікальний ідентифікатор, життєвий цикл (змінюється
внаслідок подій), порівняння не за значенням, а за ідентифікатором. Стан сутності
Міжнародний науково-технічний журнал
Проблеми керування та інформатики, 2025, № 3 77
може змінюватися, але вона залишається тією самою (наприклад, пароль користу-
вача у системі може бути змінений, але це все той самий користувач).
Рис. 2
Важливо зауважити, що на-
бору подій не завжди достатньо
для відтворення кінцевого стану
об’єкта, оскільки можуть існу-
вати певні правила, за якими ці
події застосовуються до сутнос-
ті залежно від її поточного ста-
ну. Таким чином, для того щоб
відтворити сутність, необхідно
мати послідовність подій та пра-
вила їх застосування. На відміну від подій, правила зберігаються не у сховищі
даних, а в коді. Для керування цими правилами використовується агрегована
сутність (агрегат), що являє собою групу сутностей, які логічно об’єднані в
єдине ціле і мають єдину точку входу — агрегатну сутність, або корінь агрега-
ту (aggregate root). Ці сутності відіграють критично важливу роль, оскільки
допомагають керувати змінами стану системи в організований та консистент-
ний способи. Така сутність складається з агрегатного кореня, який є єдиною
точкою входу для змін усередині агрегату і гарантує його консистентність, та
набору правил, що визначають, яким чином події впливають на сутність. Коли
відбувається зміна стану, пов’язана з агрегатом, вона створюється за допомо-
гою агрегатного кореня, який забезпечує дотримання всіх бізнес-правил та ін-
варіантів перед тим, як застосувати зміни. Також він відповідає за генерацію
подій, які будуть записані у сховище даних. Наприклад, замовлення (order) —
агрегатна сутність, яка складається з кореня, що містить загальну інформацію,
та дочірніх сутностей OrderLine, що містять інформацію про товари
в замовленні.
Такий спосіб конструювання сутностей природно забезпечує важливий ме-
ханізм патерну — відтворення їх стану. Щоб отримати стан сутності у певний
момент часу, достатньо застосувати не всі події, а лише ті, що відбулися до цьо-
го моменту. Внаслідок цього матимемо точне відтворення відповідного стану.
Водночас важливо заборонити генерацію нових подій до повного відтворення,
оскільки це призведе до появи альтернативного стану об’єкта і відповідних
конфліктів. Під час роботи системи не повинно виникати невизначеної поведін-
ки, за якої може бути порушено послідовний порядок запису подій, однак існу-
ють методи, які дають змогу це забезпечити, зокрема стратегія оптимістичного
Event
data
Database
Sinks
File
system
Apps
Subscriber
and publisher
Subscriber
Event
data
store
Publisher
Sources
Domain model Query model
APIs
Command Fetch
Event
Subscribe
Event
store ReadDB
Read
Рис. 3
78 ISSN 2786-6491
контролю одночасності або використання часових міток [8]. Необхідно зазначити,
що для симуляції альтернативних варіантів станів з метою перевірки певних гі-
потез розробники інколи штучно створюють ситуації щодо порушення послідо-
вного порядку запису [7].
Але, працюючи з цим патерном, не варто забувати, що робота з великою
кількістю подій може призвести до суттєвого зменшення швидкодії застосунку.
Щоб запобігти цьому і пришвидшити роботу критичних частин системи, викорис-
товуються снепшоти — знімки поточного стану доменної моделі на певні момен-
ти часу, що дає змогу системі пропустити частину подій при наступному віднов-
ленні стану. Тому можна створити окрему модель, що сконструйована виключно
зі снепшотів і містить обмежену інформацію про агреговану сутність, яка необ-
хідна для виконання певних операцій.
Снепшоти можуть зберігатися як разом з іншими подіями (за умови реа-
лізації як певної події зі специфічним призначенням), так і в окремому місці
із власною структурою. Переваги першого варіанта зберігання полягають
у тому, що не потрібно окремо реалізовувати снепшоти, а можна використати
наявну реалізацію збереження подій. Також у цьому разі снепшоти можна
сумістити з бізнес-подіями і тоді створювати набір подій, які будуть не лише
снепшотами, а й частиною бізнес-логіки. Вдалим прикладом таких подій є за-
криття зміни у супермаркеті, яке може містити агреговані дані про всі опера-
ції, що відбулися за цю зміну. Переваги другого варіанта, який передбачає
окрему імплементацію і збереження снепшотів ізольовано від подій, поляга-
ють у відокремленні функціонала снепшотів від подій, що ще сильніше при-
скорює відновлення станів. Однак це ускладнює технічну реалізацію і призводить
до явної дуплікації даних.
Важливо правильно обрати не лише варіант зберігання, але й умову для ство-
рення снепшотів: якщо створювати їх занадто часто, можливе перенавантаження
системи, в іншому разі — зменшення потенційних переваг від їх використання.
Існує декілька основних умов щодо частоти зберігання [9]: 1) після кожної події;
2) після визначеної кількості подій; 3) після певної події; 4) після певного
проміжку часу.
Застосування умови 1) практично не має сенсу, оскільки майже нівелю-
ється уся перевага патерну, внаслідок чого зникає потреба у записі окремих
подій. Умова 2) використовується частіше і гарантує, що під час вичитки не-
обхідно прочитати додатково не більше за ту кількість подій, після яких ро-
биться снепшот. Але головний її недолік у тому, що це ускладнює снепшот і
зазвичай передбачає збереження всієї сутності, що здебільшого не є оптималь-
ним. Умова 3) найбільше підходить для снепшоту частини інформації про
об’єкт, що, з одного боку, дозволяє не зберігати надлишкову інформацію, а
з іншого, — надає можливість для критичного прискорення важливих опера-
цій в системі, які мають вимоги до швидкодії. Однак разом з перевагами вона
має і недолік: оскільки необхідно вибрати ключову подію, яка ініціюватиме
запис створення снепшоту, це може ускладнити доменові модель, а в разі об-
рання помилкової події — сповільнити систему через велику кількість зайвих
снепшотів. Умова 4) дуже схожа на резервне копіювання. Головна перевага
в тому, що це майже не призводить до ускладнень моделі й бізнес-логіки та
має легко зрозумілий принцип роботи. Але водночас може бути вкрай неефек-
тивним для деяких систем, у яких кількість створених подій не є регулярною
і передбачуваною.
Отже, хоча снепшоти і є надзвичайно потужним механізмом, який значно
пришвидшує реконструювання об’єкта, він потребує від розробників чіткого
Міжнародний науково-технічний журнал
Проблеми керування та інформатики, 2025, № 3 79
розуміння, як і для чого вони збираються їх використати. Головні переваги
снепшотів — зменшення часу відновлення стану та оптимізація використання ре-
сурсів. Однак застосування снепшотів також має певні недоліки, як-от потен-
ційна складність керування консистентністю даних між снепшотами та подіями.
Найкраще їх використовувати в системах, де час відновлення стану критично
важливий або коли кількість подій настільки велика, що їх відновлення стає тех-
нічно затратним чи повільним.
Окрім вищезазначеного, агреговані сутності надають простір для модифі-
кацій і версіонування подій. Більшість систем постійно еволюціонує та зміню-
ється. Хоча події у цьому патерні визначено як атомарні й незмінні, проте це
стосується переважно заборони на будь-яку модифікацію подій під час роботи
системи у звичайний спосіб. Самі події та їх застосування можуть з часом змі-
нюватися у процесі розробки через зміну вимог або оптимізацію певних проце-
сів. Це може бути виражено у додаванні певних даних до якоїсь події або навпа-
ки — деякі дані події можуть втратити свою значущість і більше не використо-
вуватися. Зокрема зміни можуть бути як сумісними і не потребувати втручання
у збереження подій, так і несумісними і вимагати певних дій для забезпечення
сумісності даних після внесених змін.
Безумовно, найпростіші ті зміни, які не потребують жодних перетворень
у самих подіях і використовують старі дані без додаткових дій. До таких змін на-
лежить вилучення даних з подій (можна просто проігнорувати їх у разі наявності
у старих версіях) та додавання їх за умови, що вони необов’язкові (усі старі події
будуть сприйматися як такі, що не містять цих даних).
Набагато складніше, якщо зміни потребують або додавання нових
(обов’язкових) атрибутів, або заміни типу даних. Найпростіше рішення у та-
кому разі — створення нової події, але з часом це може призвести до значно-
го розростання класів подій і погіршити загальний стан коду. Крім цього, та-
ке рішення концептуально не є правильним, адже якщо з погляду бізнес-логіки
подія і її зміст не змінювалися, то немає підстав створювати нову подію у за-
стосунку.
Розглянемо інші підходи, які хоч і складніші, але за подальшої розробки ма-
тимуть переваги.
Одним з можливих рішень є міграція даних. Це надасть можливість позбути-
ся всіх застарілих даних і перетворити старі версії у сховищі даних на нові. Завдя-
ки цьому в коді не треба зберігати логіку роботи з попередніми версіями. Проте
найбільший недолік такого рішення — сама міграція даних, яка порушує незмін-
ність подій у системі, що є ключовим принципом патерну. У цьому разі рекомен-
довано техніку «міграції без простоїв» (migrating without any downtime) [10],
яка полягає у міграції в декілька етапів для забезпечення безперервної роботи
системи.
Перетворення старої версії на нову під час реконструювання подій — най-
більш правильний підхід з погляду патерну. Це збереже події у сховищі даних не-
змінними, а логіку їх перетворення покладе на саму систему. За таких обставин
у сховищі зберігатимуться події в їх початковому вигляді, але система сприйма-
тиме їх як події останньої версії. На рис. 4 [11] проілюстровано процес перетво-
рення подій без змін у сховищі даних. Недоліком такого підходу є розростання
логіки системи, адже вона повинна знати не тільки, як застосувати певну подію,
але й як конвертувати її в останню версію. Також така конвертація сповільнює
роботу системи, що можна компенсувати наявністю снепшотів, завдяки яким ста-
рі події використовуватимуться дедалі менше.
80 ISSN 2786-6491
Рис. 4
Переваги і недоліки патерну
Як і всі інші технології, патерн Event sourcing має низку переваг і недоліків,
на які треба зважати, коли вирішується питання про його застосування під час
розробки. Оскільки він визначає спосіб зберігання даних, то приймати рішення
треба зважено і обережно, тому що під час розробки відмовитися від патерну або
навпаки — впровадити його буде вкрай важко і потребуватиме значних зусиль
з боку розробників.
Головною перевагою патерну є можливість докладного логування всіх змін,
які відбуваються у системі. Оскільки кожна подія зберігається і записується,
у будь-який момент часу можна переглянути історію змін або відновити систему
до будь-якого попереднього стану. У разі систем з підвищеними вимогами до без-
пеки або зі складним доменом, де треба розуміти, яка послідовність подій привела
систему в поточний стан, це може бути вирішальним фактором для використання
цього патерну. Також це підвищує відмовостійкість системи завдяки можливості
швидко відновити стани подій у разі збоїв. Згідно з дослідженням половина роз-
робників, що використовують цей патерн, керувалися саме цим під час його впро-
вадження [4].
Окрім цього, існують переваги, що пов’язані з більш зручною розробкою
систем, які використовують цей патерн. По-перше, це легка інтеграція з іншими
архітектурними патернами, такими як DDD, EDA, CQRS. Така інтеграція не лише
можлива і проста в реалізації, але й дозволяє досягти ефекту синергії внаслідок
значного покращення кінцевих результатів. По-друге, — це можливість вносити
зміни в систему через додавання нових подій або модифікацію наявних. Завдяки
тому, що існують чітко прописані кроки, які потрібно зробити для внесення змін,
розробники можуть знизити ймовірність проблем під час розробки і еволюції сис-
теми та без зайвих ризиків працювати зі змінами будь-якої складності. Саме цими
перевагами керуються 65 % розробників [4], що засвідчує, що зручність розробки,
яку забезпечує патерн, більш важлива, ніж його основна функціональність у ви-
гляді роботи з історичними даними.
Зауважимо, що є і низка недоліків, які можуть стати важливим фактором,
чому не варто застосовувати цей патерн. Головний з них — необхідність збері-
гання великої кількості подій, внаслідок чого можливе значне зростання обсягу
даних [4] і, відповідно, створення викликів, пов’язаних з керуванням даними, їх-
ньою архівацією та процесом відновлення. Для певних систем, атрибути яких час-
то змінюються і перезаписуються, в рази може збільшитися обсяг даних, що збе-
рігаються. А необхідність мати всю послідовність подій разом для реконструю-
вання стану унеможливлює архівування частини або навіть видалення застарілих
даних.
Міжнародний науково-технічний журнал
Проблеми керування та інформатики, 2025, № 3 81
Крім викликів, які пов’язані зі сховищем даних, існують також інші —
пов’язані з самими розробниками. Реалізація Event sourcing потребує більш склад-
ної архітектури порівняно з традиційними підходами. Розробники повинні врахо-
вувати логіку як застосунку, так і збереження подій, що може ускладнити проєкт і
потребувати висококваліфікованих фахівців. А оскільки для ефективного викорис-
тання Event sourcing важливе глибоке розуміння доменної області, то розробники
повинні ще й мати певну експертизу, що, відповідно, ще більше ускладнює поріг
входу. Недостатнє розуміння і брак кваліфікації можуть призвести до неправиль-
ного моделювання подій, тобто підвищення складності внесення змін у майбут-
ньому та розширення системи.
Окремо слід виділити незмінність подій — одну з ключових особливостей
патерну. На відміну від інших це є водночас і перевагою, і недоліком. З одного
боку, незмінність гарантує, що історія подій зберігається без змін. А отже, забез-
печує високий рівень довіри до аудиту, надаючи змогу системі точно відтворюва-
ти стан на будь-який момент часу. З іншого боку, незмінність може стати недолі-
ком, коли виникає необхідність вносити зміни у вже зареєстровані події. Це мож-
ливо у разі помилок або коли потрібно внести корективи, що відповідають
зміненим обставинам або законодавчим вимогам. У таких випадках система по-
винна включати механізми для обробки виправлень, наприклад введення нових
подій, які компенсують або анулюють ефект попередніх. Це збільшує складність
системи та може вплинути на її продуктивність та простоту керування.
Застосування патерну
На жаль, не так багато відомих компаній відкривають деталі технічної реалі-
зації своїх застосунків, тому важко відслідкувати, наскільки цей патерн дійсно є
поширеним. Непрямим доказом може бути лише список партнерів, які використо-
вують EventStoreDB [12] — одну з найбільш відомих баз даних, що спеціалізуєть-
ся саме на збереженні подій.
На їх фоні виділяється компанія Netflix, фахівці якої в технічному блозі сер-
вісу розкривають деталі використання Event sourcing [13]. Розробники Netflix за-
стосовують патерн Event sourcing для керування завантаженнями контенту, що
дає змогу користувачам зберігати фільми та серіали на своїх пристроях для пере-
гляду без мережі. Цей підхід вони обрали через його спроможність забезпечувати
високу масштабованість, відмовостійкість та надійність, що критично важливо
для сервісу з мільйонами користувачів по всьому світу.
Кожна активність користувача, така як запит на завантаження, пауза, віднов-
лення або скасування завантаження, реєструється як окрема подія. Ці події надхо-
дять у систему, де вони агрегуються та обробляються. Завдяки цьому підходу Net-
flix може точно відновлювати стан системи завантажень у будь-який момент, пе-
ревіряти коректність станів та аналізувати поведінку користувачів.
Для оптимізації розробники впровадили снепшоти для станів, які найчастіше
запитуються, що значно зменшило затримку і навантаження на базу даних. А для
того щоб керувати великим обсягом подій, Netflix використовує розподілені сис-
теми та асинхронну обробку, що надає системі змогу ефективно масштабуватися і
витримувати високі навантаження.
Найбільшим викликом для Netflix було забезпечення консистентності даних
між різними компонентами системи, що вирішено за допомогою ретельно сплано-
ваних механізмів синхронізації та впровадження надійних стратегій відновлення
після збоїв.
Таким чином, внаслідок імплементації патерну Event sourcing сервіс Netflix
зміг забезпечити високий рівень надійності, доступності та масштабованості для
82 ISSN 2786-6491
своєї глобальної платформи скачувань. За допомогою цього підходу можна де-
тально логувати всі зміни в системі, відновлювати попередні стани у разі потре-
би та проводити глибокі аудити. Масштабування обробки подій, кешування ста-
ну сервісів та оптимізація зберігання даних — ключові аспекти, що сприяли
зменшенню навантаження на систему і забезпеченню швидкої відповіді на запи-
ти користувачів.
Незважаючи на те, що цей патерн вперше описано у 2005 році [1], станом на
2023 рік у відкритому доступі існує не так багато готових рішень, які спрощували
б його імплементацію.
У більшості наявного на 2023 рік матеріалу надано не готові рішення, а лише
невеликі керівництва з використання цього патерну. Зазвичай вони містять міні-
мальну реалізацію для демонстрації можливостей патерну, що є, безумовно, корис-
ним для розробників, які хочуть вивчити цей патерн, але не демонструють, як ви-
рішити головні проблеми, з якими стикаються розробники під час його викорис-
тання. Такі рішення хоч і можуть бути хорошою точкою входу для тих, хто
вирішив застосувати цей патерн, але вони ще не готові для використання у справж-
ніх додатках, які оперують великою кількістю даних.
Тим не менш, у відкритому доступі можна знайти фреймворки для таких мов,
як .Net, Elixir, Typescript, Python, Php, Java.
Незважаючи на велику кількість мов, що мають імплементації для вико-
ристання патерну, станом на 2023 рік лише в .NET є декілька реалізацій, се-
ред яких розробники можуть обирати. Усі інші мови мають лише одну реалі-
зацію.
Фреймворки, які реалізують Event sourcing, часто нішеві й тому рідко дося-
гають значної популярності (якщо орієнтуватися на кількість зірок у відповідних
проєктах на GitHub, де міститься код цих фреймворків), що свідчить про специ-
фічність кола застосування й аудиторії. Проте з-поміж усіх виокремлюються рі-
шення на .NET та Python, значно популярніші за їх аналоги іншими мовами. Вна-
слідок своєї функціональності та спільності вони підтримують високий рівень ін-
тересу та розвитку серед своїх користувачів.
Більшість наявних фреймворків реалізує ключові можливості патерну Event
sourcing, однак вони роблять це з різним рівнем успіху та зручності для кінцево-
го користувача. Усі проаналізовані фреймворки обмежені внаслідок підтримки
інтеграції тільки з певними сховищами даних і не надають можливості для реалі-
зації власної інтеграції з іншими системами зберігання. Також важливо зазначити,
що у них немає реалізації часткових снепшотів, що може бути критичним для де-
яких застосувань. Лише декілька з них підтримує асинхронну обробку подій, що
важливо для систем з високими вимогами до продуктивності та відгуків.
Згідно з результатами аналізу наявних фреймворків можна дійти висновку,
що вони не можуть повноцінно розкрити весь потенціал цього патерну та містять
низку недоліків, що може обмежувати їх ефективність у певних сценаріях засто-
сування. Ці обмеження підкреслюють необхідність у розробці нового фреймвор-
ку, який виправив би наявні недоліки та розширив можливості розробників при
використанні патерну Event sourcing. Створення такого рішення забезпечило би
більш гнучке керування даними, оптимізувало відновлення станів системи і га-
рантувало асинхронну підтримку. Це зробить можливим впровадження даного
патерну в масштабних застосуваннях з певними вимогами. Таким чином, розроб-
ка фреймворку, який враховує ці потреби, стає важливим кроком на шляху до
вдосконалення архітектурних практик та технологій в галузі програмування. Саме
цим і плануємо зайнятися в майбутньому.
Міжнародний науково-технічний журнал
Проблеми керування та інформатики, 2025, № 3 83
Висновок
Патерн Event sourcing пропонує низку значних переваг, які можуть бути ви-
рішальними для систем з високими вимогами до документування змін і аудиту.
Він дає змогу детально відслідковувати історію змін, відновлювати систему до
будь-якого попереднього стану та інтегрується із сучасними архітектурними па-
тернами, підвищуючи гнучкість та ефективність розробки. Але разом з перевага-
ми Event sourcing несе в собі й певні виклики (наприклад, потребу в збереженні
великої кількості подій), що може призвести до збільшення обсягу даних та вима-
гати від розробників глибшого розуміння домену та складніших технічних рі-
шень. Незмінність подій, хоча і є ключовою особливістю, також може додати
складності у випадках, коли потрібно коригувати минулі записи. Тому прийняття
рішення про використання патерну повинно базуватися на глибокому аналізі спе-
цифіки проєкту та потенційних вигід і труднощів, які можуть виникнути. Важли-
во зважити всі переваги і можливі проблеми перед впровадженням цього патерну
в розробку, щоб забезпечити максимальну ефективність і адаптацію до потреб
системи.
Event sourcing — потужний патерн проєктування, який використовується
в різноманітних галузях для забезпечення детального логування змін, відновлення
стану системи та високої надійності. Він особливо корисний там, де критично
важливим є точне відстеження історії транзакцій або станів, наприклад у фінансо-
вих послугах, електронній комерції, ігровій індустрії, охороні здоров’я та високо-
навантажених системах обробки даних.
Патерн добре підходить для комплексних систем, де потрібно відновлювати
попередні стани, аналізувати зміни або забезпечувати високий рівень надійнос-
ті. Завдяки своїй сумісності з іншими архітектурними патернами, такими як
CQRS та DDD, Event sourcing може інтегруватися у широкий спектр програмних
рішень, збільшуючи їхню ефективність та оптимізуючи керування даними і біз-
нес-процесами.
Цей патерн може застосовуватися не до всієї системи, а лише до окремих,
найбільш критичних її частин, які потребують додаткового рівня контролю і пе-
ревірок, що ще більше розширює можливі сфери його застосування.
A. Hlybovets, I. Yankin
EVENT SOURCING PATTERN
AND ITS APPLICATION
Andrii Hlybovets
National University of Kyiv-Mohyla Academy, Kyiv,
a.glybovets@ukma.edu.ua
Ihor Yankin
National University of Kyiv-Mohyla Academy, Kyiv,
ihor.yankin@ukma.edu.ua
The article discusses Event sourcing pattern that used in programming dis-
tributed systems that require reliable storage of change history and high fault
tolerance. It describes the theoretical foundations of the pattern, its architecture,
and key components, as well as compares it with other approaches to developing
complex software systems. The Event sourcing pattern ensures the preservation
of the system’s state through a sequence of events, allowing for effective
mailto:a.glybovets@ukma.edu.ua
mailto:ihor.yankin@ukma.edu.ua
84 ISSN 2786-6491
recovery of previous states and maintaining reliability in scalable solutions. In
particular, the article analyzes the use of this approach in companies like Netflix,
which ensures high fault tolerance and scalability for their content download
platform. The authors emphasize the need for the development of new frame-
works to simplify the implementation of the pattern in various programming
languages such as .NET, Python, Elixir, Java, and others. It is noted that most
existing solutions have limited integration with databases and do not support
asynchronous event processing, which restricts their use in demanding systems.
Special attention is given to the challenges that arise when using Event sourcing
such as the need to store a large number of events, which may increase the
volume of data, and the inability to edit past records. The article also highlights
the importance of evaluating the advantages and difficulties of applying the pat-
tern before its implementation in real projects. The pattern works well with other
architectural practices such as CQRS and DDD and can be used to optimize data
management and business processes in complex software solutions. The result of
the research is a comprehensive analysis of the use of the pattern for effective
event handling in software projects, which significantly improves the quality, re-
liability, flexibility, and scalability of the developed software.
Keywords: application, software systems architecture, programming patterns,
asynchronous, reliability, scalability.
REFERENCES
1. Fowler M. Event Sourcing (12.12.2005). Website of Martin Fowler. URL: https://martinfowler.
com/eaaDev/EventSourcing.html
2. Глибовець А.М. Агентно-базовані програмні системи пошуку та аналізу інформації. Київ :
Видавничий дім «Києво-Могилянська академія», 2019. 278 c.
3. Breaking down the numbers: how much data does the world create daily in 2024? (11.03.2024).
Edge Delta. URL: https://edgedelta.com/company/blog/how-much-data-is-created-per-day/
4. An empirical characterization of event sourced systems and their schema evolution – lessons from
industry / M. Overeem, M. Spoor, S. Jansen, S. Brinkkemper. Journal of Systems and Software.
2021. Vol. 178. ID: 110970. 20 p. DOI: https://doi.org/10.1016/j.jss.2021.110970
5. Chaojie Xiao. Domain-driven design practice — Domain Events. (09.10.2022). Medium. URL:
https://medium.com/@chaojie.xiao/domain-driven-design-practice-domain-events-15b38f3c58fc/
6. What is Event-Driven Architecture? Hazelcast. URL: https://hazelcast.com/glossary/event-
driven-architecture/
7. Improving observability in Event Sourcing systems / S. Lima, J. Correia, F. Araujo, J. Cardoso.
Journal of Systems and Software. 2021. Vol. 181. ID: 111015. 12 p. DOI: https://doi.org/10.
1016/j.jss.2021.111015
8. Event sourcing pattern. AWS Documentation. URL: https://docs.aws.amazon.com/prescriptive-
guidance/latest/cloud-design-patterns/event-sourcing.html
9. Dudycz O. Snapshots in Event Sourcing. (20.05.2021). Kurrent. URL: https://www.eventstore.
com/blog/snapshots-in-event-sourcing#when-to-take-a-snapshot
10. Stebunov D. Migrating a production database without any downtime. (16.10.2024). Ivelum. URL:
https://teamplify.com/blog/zero-downtime-DB-migrations
11. Event Sourcing: events evolution, versioning, and migration. (03.06.2021). Val’s Tech Blog.
URL: https://valerii-udodov.com/posts/event-sourcing/events-versioning
12. Kurrent. URL: https://www.eventstore.com/
13. Scaling Event Sourcing for Netflix downloads, episode 1 / K. Casella, Ph. Avery, R. Reta,
J. Breuer. (11.09.2017). Medium. URL: https://netflixtechblog.com/scaling-event-sourcing-for-
netflix-downloads-episode-1-6bc1595c5595
Отримано 11.02.2025
https://edgedelta.com/company/blog/how-much-data-is-created-per-day/
https://www.sciencedirect.com/journal/journal-of-systems-and-software
https://doi.org/10.1016/j.jss.2021.110970
https://medium.com/@chaojie.xiao/domain-driven-design-practice-domain-events-15b38f3c58fc/
https://hazelcast.com/glossary/event-driven-architecture/
https://hazelcast.com/glossary/event-driven-architecture/
https://www.sciencedirect.com/journal/journal-of-systems-and-software
https://doi.org/10.1016/j.jss.2021.111015
https://doi.org/10.1016/j.jss.2021.111015
https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/event-sourcing.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/event-sourcing.html
https://teamplify.com/blog/zero-downtime-DB-migrations
|
| id | nasplib_isofts_kiev_ua-123456789-211403 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 0572-2691 |
| language | Ukrainian |
| last_indexed | 2026-03-16T06:39:43Z |
| publishDate | 2025 |
| publisher | Інститут кібернетики ім. В.М. Глушкова НАН України |
| record_format | dspace |
| spelling | Глибовець, А.М. Янкін, І.С. 2026-01-01T19:43:15Z 2025 Патерн Event sourcing та його застосування / А.М.Глибовець, І.С.Янкін // Проблемы управления и информатики. — 2025. — № 3. — С. 74-84. — Бібліогр.: 13 назв. — укр. 0572-2691 https://nasplib.isofts.kiev.ua/handle/123456789/211403 004.42 10.34229/1028-0979-2025-3-7 У статті розглядається застосування патерну Event sourcing у програмуванні розподілених систем, які потребують надійного збереження історії змін і забезпечення високої відмовостійкості. Описано теоретичні основи патерну, його архітектуру та ключові компоненти, а також проведено порівняння з іншими підходами щодо розробки складних програмних систем. The article discusses Event sourcing pattern that used in programming distributed systems that require reliable storage of change history and high fault tolerance. It describes the theoretical foundations of the pattern, its architecture, and key components, as well as compares it with other approaches to developing complex software systems. uk Інститут кібернетики ім. В.М. Глушкова НАН України Проблеми керування та інформатики Роботи та системи штучного інтелекту Патерн Event sourcing та його застосування Event sourcing pattern and its application Article published earlier |
| spellingShingle | Патерн Event sourcing та його застосування Глибовець, А.М. Янкін, І.С. Роботи та системи штучного інтелекту |
| title | Патерн Event sourcing та його застосування |
| title_alt | Event sourcing pattern and its application |
| title_full | Патерн Event sourcing та його застосування |
| title_fullStr | Патерн Event sourcing та його застосування |
| title_full_unstemmed | Патерн Event sourcing та його застосування |
| title_short | Патерн Event sourcing та його застосування |
| title_sort | патерн event sourcing та його застосування |
| topic | Роботи та системи штучного інтелекту |
| topic_facet | Роботи та системи штучного інтелекту |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/211403 |
| work_keys_str_mv | AT glibovecʹam paterneventsourcingtaiogozastosuvannâ AT ânkínís paterneventsourcingtaiogozastosuvannâ AT glibovecʹam eventsourcingpatternanditsapplication AT ânkínís eventsourcingpatternanditsapplication |