У цьому матеріалі Артем Ляшанов розбирає, що таке EDA, у чому її відмінність від мікросервісів, де вона застосовується у фінтеху і які обмеження важливо знати заздалегідь.
Що таке EDA
EDA – це модель, за якою різні частини системи обмінюються інформацією не напряму, а через події. Короткі повідомлення про те, що щось відбулося.
У традиційному підході одна частина системи звертається до іншої із запитом і чекає на відповідь, перш ніж продовжити роботу. В EDA частина системи натомість публікує повідомлення про подію, а ті, кому ця інформація потрібна, самостійно її обробляють, без прямого звернення одне до одного.
У цій моделі прийнято виділяти три ролі:
- Продюсер (producer) як джерело події, наприклад сервіс, який щойно обробив транзакцію;
- Брокер (broker) як проміжний компонент, що приймає повідомлення, зберігає їхній порядок і передає тим системам, які на них підписані;
- Консюмер (consumer) як система, яка підписана на певний тип подій і реагує на них.
Разом ці три ролі утворюють цикл, у якому жодна зі сторін не залежить напряму від стану чи доступності іншої. Саме ця відсутність прямого зв'язку і лежить в основі гнучкості подієвої архітектури.
Чим це відрізняється від мікросервісів
EDA і мікросервіси пов'язані, але не тотожні поняття. Мікросервіси описують, як розділити систему на окремі незалежні компоненти. EDA описує, яким способом ці компоненти обмінюються інформацією між собою.
Мікросервіси можуть спілкуватися між собою прямими запитами, без подієвої моделі. Але коли їх поєднують саме через події, це, за поширеною оцінкою, дає їм додаткову незалежність. Один компонент можна тимчасово вивести з роботи, а накопичені події будуть оброблені пізніше, коли він знову стане доступний.
Де це застосовується у фінтеху
У фінансовому секторі різниця між очікуванням відповіді та реакцією без очікування часто має пряме значення для швидкості виявлення проблем.
Серед прикладів застосування, які найчастіше згадуються:
- Банки та фінтех-платформи поєднують історію витрат клієнта з поточною активністю, щоб швидше формувати релевантні пропозиції;
- Окремі системи можуть реагувати на аномалії в поведінці рахунку одразу після їх появи, а не за результатами періодичної перевірки;
- В окремих галузях, зокрема авіаперевезеннях, подібний підхід використовують для оперативної зміни цін залежно від попиту.
Спільне в цих прикладах не швидкість сама по собі, а те, що кожна система реагує на подію незалежно від інших, без єдиної точки, через яку мав би пройти весь потік даних.
Обмеження підходу
EDA має і низку практичних складнощів, які варто враховувати при виборі архітектури.
Один з них це тимчасова неузгодженість даних. Різні частини системи можуть протягом короткого часу відображати не найновішу інформацію. Для одних сценаріїв це малопомітно, для фінансових операцій це питання, що вимагає окремого проєктування.
Інша складність це обробка дублікатів повідомлень, якщо подія через збій надійшла двічі, система має бути спроєктована так, щоб не виконати дію повторно. Ця властивість у галузі має назву ідемпотентність.
Третя складність стосується діагностики, коли подія проходить через кілька систем-підписників, пошук першопричини проблеми може вимагати більше часу й окремих інструментів моніторингу, ніж у системах із прямими запитами.
Коли перехід на EDA виправданий
Засновник фінтех-проєктів Артем Ляшанов вважає, що рішення про перехід на подієву архітектуру варто ухвалювати не за принципом технологічної моди, а виходячи з конкретного критерію і наводить для цього два аргументи.
По-перше, сам перехід на подієву модель не усуває бізнес-ризику, пов'язаного з неузгодженістю даних. Якщо ця робота не зроблена свідомо, перехід на EDA не спрощує систему, а лише ховає складність в іншому місці.
По-друге, перевага у гнучкості й масштабованості проявляється тільки тоді, коли на один потік подій реально підписана значна кількість незалежних систем. Для продукту, де є лише два-три сервіси, витрати на впровадження й підтримку окремого брокера подій можуть перевищити практичну користь від переходу.
Виходячи з цього, Артем Ляшанов пропонує оцінювати доцільність EDA за тим, скільки незалежних систем справді повинні реагувати на одну й ту саму подію одночасно, і чи готова команда закласти час на проєктування узгодженості даних, а не лише на впровадження самого брокера.
Чому нам можна довіряти
Ми пишемо про архітектуру з позиції практика: кожен висновок спирається на реальні проєкти у сфері платежів і на відкриті матеріали. Ми не продаємо конкретні платформи і не називаємо рішення універсальними.
Як ми перевіряємо інформацію
Технічні твердження звіряємо з публічними рекомендаціями NIST, ENISA та вимогами стандарту ISO/IEC 27001. Якщо дані застаріли або з'явилися нові практики, ми оновлюємо матеріал і вказуємо дату змін.
Подієва архітектура не робить систему надійнішою автоматично. Вона робить її гнучкішою і вимагає більшої дисципліни в проєктуванні даних. — Артем Ляшанов