Rate this post

Якщо ви постійно чуєте про Apache Kafka, але так і не збагнули, що це таке і чому всі про неї говорять — ця стаття нарешті поставить усе на свої місця.
Ми розберемо Kafka на реальних прикладах, використовуючи вигаданий e-commerce застосунок StreamStore, і подивимось, як Kafka вирішує біль, з якою стикається майже кожна сучасна архітектура.

Проблема: коли мікросервіси перетворюються на доміно

У нашому StreamStore працюють мікросервіси:

  • замовлення

  • платежі

  • склад

  • сповіщення

  • аналітика

Коли користувач оформляє замовлення, у системі запускається цілий ланцюг подій:

  • зменшення залишку на складі

  • надсилання email клієнту

  • створення інвойсу

  • оновлення панелі продажів

  • оновлення статистики виручки

Ми — невеликий стартап, тому на початку робимо все максимально просто:
мікросервіси напряму викликають один одного.

Order → Payment → Inventory → Notification → Analytics

І все працює… поки не настає Black Friday.

Раптом:

  • застосунок починає гальмувати

  • користувачі сидять перед вічними екранами завантаження

  • сервіси падають під навантаженням

  • продажі втрачаються щохвилини

  • архітектура перетворюється на хаос

Що ж сталося?

Чому пряме взаємодіяння мікросервісів — це пастка

1. Жорстка зв’язаність

Якщо сервіс платежів падає — весь процес оформлення замовлення зупиняється.

2. Синхронні виклики

Кожен крок чекає наступного — як довга лінія доміно.
Один повільний сервіс → усе сповільнюється.

3. Точки відмови

10 хвилин простою складу = 2 години накопичених замовлень.

4. Втрата даних

Аналітика впала на годину → втрачено годину даних про продажі.

Нам потрібна архітектура, де події проходять крізь систему
природним потоком, а не у вигляді нескінченного ланцюжка викликів.

Рішення: Kafka як “поштове відділення” системи

Замість того, щоб сервіси напряму дергали один одного, ми додаємо брокер — посередника між ними.

Kafka = поштова служба для мікросервісів:

  • Відправник (Order Service) кладе “пакунок” (event)

  • Пошта (Kafka) приймає і зберігає його

  • Отримувачі (Inventory, Notification, Payments тощо) забирають, коли готові

Ніяких очікувань. Ніяких прямих викликів. Ніяких зависань.

Producers і Events: як дані потрапляють у Kafka

Order Service стає producer-ом.
Він створює подію:

“Створено замовлення: клієнт X, товари Y, деталі Z.”

І відправляє її в Kafka.

Подія — це простий об’єкт із ключем, значенням та метаданими.

Після відправлення сервіс не чекає, чи хтось отримав це повідомлення.
Він просто продовжує роботу.

Де зберігаються події? Kafka Topics

Kafka групує події в топіки — як окремі черги в поштовому відділенні:

  • orders

  • payments

  • inventory

  • notifications

Нічого не складається у величезний безлад.
Топіки створюєте ви — як схеми в базі даних.

Consumers: сервіси, які реагують на події

Коли в orders з’являється подія “створено замовлення”, підписники отримують її:

  • Notification Service → надсилає лист

  • Inventory Service → зменшує залишок

  • Payment Service → створює інвойс

  • Analytics Service → оновлює статистику

Кожен працює у своєму темпі, незалежно від інших.

Kafka — це база даних? Ні, й ось чому

Kafka зберігає події, але не замінює основну БД.

Наприклад:

  • Склад оновлює залишки в базі

  • Але також генерує подію оновлення складу, щоб:

    • спрацювали оповіщення про низький залишок

    • сервіс авто-поповнення зробив нове замовлення

    • аналітика могла працювати в реальному часі

Kafka — це не стан.
Kafka — це історія змін.

Потокова обробка в реальному часі: Kafka Streams

Деяким застосункам потрібне постійне оновлення:

  • realtime панель продажів

  • геолокація водіїв в Uber

  • постійна перевірка складських порогів

Для цього Kafka пропонує Streams API — потокову обробку подій.

Streams працюють не “одна подія → одна дія”, а безперервним потоком.

Масштабованість Kafka: Partitions

Kafka масштабується завдяки партиціям.

Уявіть:
у поштовому відділенні додали більше працівників у кожен розділ:

  • листи до Європи → працівник A

  • листи до США → працівник B

  • листи до Азії → працівник C

У Kafka так само:

  • orders-eu

  • orders-us

  • orders-asia

Різні продюсери можуть писати в різні партиції паралельно.

Прискорюємо обробку: Consumer Groups

Якщо один сервіс не встигає обробляти потік даних — запускаємо кілька його копій.

Kafka автоматично:

  • об’єднує їх за group ID

  • розподіляє партиції між ними

  • переносить навантаження, якщо одна копія падає

Це забезпечує горизонтальне масштабування.

Де фізично зберігаються дані? Kafka Brokers

Kafka працює на кластері серверів — broker-ів.

Брокери:

  • зберігають дані на дисках

  • приймають запити

  • реплікують дані

  • забезпечують відмовостійкість

Kafka зберігає події стільки, скільки ви вкажете в retention policy.

Це головна відмінність від звичайних черг, які видаляють повідомлення після обробки.

Kafka vs класичні черги: Netflix проти телебачення

Звичайна черга — як телебачення:

  • дивишся те, що показують

  • у той час, коли показують

  • пропустив — все, втратив

Kafka — як Netflix:

  • дивишся що хочеш

  • коли хочеш

  • у своєму темпі

  • можеш переглядати знову

Саме ця гнучкість робить Kafka унікальною.

Прощавай, ZooKeeper: вітаємо, KRaft

Раніше Kafka використовувала ZooKeeper для координації.
Сучасні версії перейшли на KRaft, вбудовану систему керування.

Це спрощує конфігурацію та зменшує кількість залежностей.

Висновок

Kafka — це не просто message broker.
Це потужна платформа для потокової обробки даних, яка вирішує:

  • жорстку зв’язаність

  • проблеми синхронних викликів

  • втрату даних

  • неможливість realtime аналітики

  • проблеми масштабування

Якщо ця стаття допомогла вам нарешті зрозуміти Kafka — поділіться нею з колегою, якому вона теж стане у пригоді.