Event-driven архітектура на практиці

Навіщо розривати прямий зв'язок між сервісами

У класичній синхронній архітектурі сервіс А напряму викликає сервіс Б по HTTP і чекає відповіді. Це просто, але крихко: якщо Б недоступний або повільний, А теж починає деградувати. Event-driven підхід розриває цей зв'язок — сервіс публікує подію в чергу і не чекає, поки хтось її обробить. Детальніше про суміжний підхід можна прочитати в матеріалі «Rate limiting: алгоритми та реалізація».

Підводні камені

Головна пастка — ілюзія, що асинхронність вирішує всі проблеми узгодженості даних. Насправді вона змінює один клас проблем на інший: замість синхронних тайм-аутів ви отримуєте eventual consistency і необхідність проєктувати систему так, щоб вона коректно працювала, поки подія ще не оброблена.

Другий частий провал — відсутність ідемпотентності в обробників. Черги повідомлень здебільшого гарантують доставку «принаймні один раз», а отже, обробник рано чи пізно отримає дублікат події і повинен вміти безпечно його ігнорувати. Без цього правила event-driven система рано чи пізно почне списувати гроші двічі або надсилати листи по колу. Ці ідеї перегукуються з темами «GraphQL vs REST у 2026: що обрати» та «CI/CD пайплайни з GitHub Actions: від нуля до продакшену».