У 2026 році Kafka Streams виповнюється десять років. Фреймворк потокової обробки, що є частиною проєкту Apache Kafka під егідою Apache Software Foundation, давно вийшов за межі «додатку до брокера» і став основою місійно критичних систем у великих компаній. У свіжому епізоді Confluent Developer Podcast співрозмовником ведучого Тіма Берглунда став Матіас Й. Сакс, один із ключових контриб’юторів Kafka Streams. На тлі ювілею вони детально обговорили, як розробники сьогодні будують і тестують стрімінгові застосунки — через високорівневий DSL, низькорівневий Processor API та утиліту TopologyTestDriver, а також які зміни готуються для більш реалістичного тестування багатопартиційних топіків.
DSL проти Processor API: два обличчя Kafka Streams
Архітектура Kafka Streams з самого початку будувалася як компроміс між зручністю та контролем. Цей компроміс матеріалізувався у двох основних програмних інтерфейсах: високорівневому DSL та низькорівневому Processor API.
DSL (Domain-Specific Language) — це те, з чим стикається більшість розробників, коли вони вперше беруться за Kafka Streams. Він надає «флюєнтний» інтерфейс для опису топології обробки: потоки можна фільтрувати, групувати, агрегувати, приєднувати, трансформувати, не замислюючись про деталі внутрішньої реалізації. Код виглядає як послідовність декларативних операцій над потоками даних, де кожен крок логічно випливає з попереднього.
Цей підхід добре масштабується в командах, де важливо швидко будувати бізнес-логіку, не занурюючись у тонкощі керування станом, розподілу партицій чи внутрішніх протоколів. DSL приховує складність, дозволяючи мислити категоріями «що робити з даними», а не «як саме це реалізувати на рівні кожного запису».
На іншому полюсі — Processor API. Це нижчий рівень, де розробник отримує доступ до обробки кожного запису окремо та прямий доступ до state stores. Тут уже немає зручних ланцюжків з filter і aggregate; натомість є процесори, які викликаються для кожного повідомлення, і явні виклики до сховищ стану. Processor API дає повний контроль над логікою, продуктивністю, схемою доступу до даних і навіть тим, як саме організовано зберігання.
Такий рівень контролю потрібен там, де DSL виявляється надто обмежувальним: наприклад, коли потрібні нетипові патерни обробки, складні взаємодії з кількома state stores, специфічна оптимізація під навантаження або нестандартні гарантії щодо порядку обробки. Не дивно, що частина користувачів свідомо обирає будувати все виключно на Processor API, жертвуючи зручністю заради передбачуваності поведінки та тонкого налаштування продуктивності.
Гібридний підхід: коли DSL і Processor API працюють разом
Попри те, що DSL і Processor API часто протиставляють, Kafka Streams дозволяє поєднувати їх в одній топології. Це важливий, але не завжди очевидний для новачків аспект: розробник може описати більшу частину обробки через DSL, а в окремих вузлах «вбудувати» власні процесори, написані на Processor API.
Технічно це виглядає як вставка кастомних процесорів у топологію, визначену DSL. Потік даних проходить через стандартні операції на кшталт map, filter, groupByKey, а в певний момент потрапляє в користувацький процесор, де вже доступний повний низькорівневий контроль: можна напряму працювати зі state stores, реалізовувати нетривіальні алгоритми, змінювати структуру даних, керувати побічними ефектами.
Такий гібридний підхід дозволяє уникнути крайнощів. Замість того щоб повністю відмовлятися від DSL через одну-дві «нестандартні» ділянки логіки, команда може залишити більшість коду на високому рівні, а Processor API застосувати лише там, де це дійсно виправдано. Це знижує поріг входу для нових розробників, спрощує супровід і водночас не обмежує можливості системи.
Втім, є й інший табір: деякі користувачі свідомо будують усе виключно на Processor API. Мотивація тут зрозуміла. Коли система працює під екстремальним навантаженням або виконує критично важливі функції, максимальна прозорість і контроль над кожним кроком обробки стають пріоритетом. Processor API дає змогу точно знати, що відбувається з кожним записом, як організований доступ до стану, як поводиться застосунок під час відмов і відновлень. Для таких команд додатковий рівень абстракції DSL — це не допомога, а потенційне джерело невизначеності.
У результаті Kafka Streams фактично підтримує три стилі розробки: «чистий» DSL, «чистий» Processor API та гібридний варіант. Вибір між ними визначається не лише технічними вимогами, а й культурою команди, її досвідом у розподілених системах і готовністю інвестувати час у глибоке розуміння внутрішньої кухні фреймворку.
Як TopologyTestDriver перетворює тестування Streams на звичайні unit-тести
Як тільки мова заходить про складні стрімінгові топології, неминуче постає питання: як усе це тестувати? Історично розробникам доводилося запускати тестові кластери Kafka, використовувати testcontainers або інші інструменти для інтеграційних тестів. Це давало реалістичну картину, але було важким, повільним і погано підходило для швидких ітерацій.
Kafka Streams відповіла на цю проблему утилітою TopologyTestDriver. По суті, це засіб для unit-тестування, який симулює середовище виконання Kafka Streams без реального кластера Kafka. Розробник бере свою топологію — незалежно від того, побудована вона через DSL, Processor API чи їхню комбінацію, — і «підключає» її до тест-драйвера.
Далі сценарій виглядає дуже схожим на звичайні unit-тести. Створюються вхідні та вихідні топіки в межах TopologyTestDriver. У вхідні топіки подаються тестові записи, після чого з вихідних топіків зчитуються результати, над якими виконуються звичні для тестів перевірки: порівняння значень, перевірка порядку, наявності чи відсутності певних ключів тощо.
Ключова перевага такого підходу — затримка вимірюється мілісекундами. Немає мережевих викликів до брокера, немає запуску контейнерів, немає очікування, поки підніметься кластер. Дані «прокачуються» через топологію майже миттєво, що робить цикл «змінив код — запустив тести — отримав зворотний зв’язок» надзвичайно коротким. Для команд, які активно практикують TDD або просто покладаються на щільне покриття unit-тестами, це суттєво змінює досвід розробки.
Це не означає, що інтеграційні тести з реальним кластером стають непотрібними. Навпаки, у багатьох випадках комбінація обох підходів — єдиний спосіб упевнитися, що система працює коректно як на рівні бізнес-логіки, так і на рівні інфраструктури. Але TopologyTestDriver дозволяє винести значну частину перевірок на рівень unit-тестів, де вони дешевші, швидші й простіші в обслуговуванні.
Не дивно, що саме обмеження TopologyTestDriver стало предметом окремої ініціативи з боку спільноти. І тут на сцену виходить Michelin — один із найактивніших користувачів Kafka Streams.
Michelin, scaffolding і боротьба за реалістичне багатопартиційне тестування
Michelin — важкий користувач Kafka Streams, який побудував навколо фреймворку власне «scaffolding» для внутрішнього використання. Ці надбудови спрощують розробку, стандартизують підходи до обробки та тестування, а також закривають прогалини, які команда виявила в базовому API. Важливо, що Michelin відкрив цей код на GitHub, а інженери компанії пішли далі й почали вносити свої напрацювання назад у Kafka Streams через KIP-и (Kafka Improvement Proposals).
Деякі з цих ідей уже стали частиною основного проєкту. Покращена обробка винятків, включно з можливістю тонко налаштовувати реакцію на помилки, — один із таких прикладів. Інший — поява dead letter queue (DLQ) як повноцінної функції Kafka Streams. Те, що колись було внутрішнім патерном у Michelin, тепер доступне всім користувачам фреймворку.
Наступна ціль — TopologyTestDriver. Головне обмеження утиліти сьогодні полягає в тому, що вона моделює кожен вхідний топік лише з однією партицією. Для багатьох сценаріїв цього достатньо, але як тільки логіка застосунку залежить від розподілу ключів по партиціях, від стратегії keying або від поведінки при ребалансі, така модель стає надто спрощеною.
У реальному продакшені топіки майже завжди багатопартиційні. Від того, як саме ключі розподіляються між партиціями, залежить локальність стану, навантаження на окремі інстанси, поведінка при масштабуванні та відмовах. Якщо тестове середовище завжди працює з однією партицією, воно не дозволяє виявити цілий клас помилок: від неправильного вибору ключа до неочікуваних «гарячих» партицій.
Саме тому інженери Michelin запропонували KIP, який робить TopologyTestDriver «multi-partition aware». Ідея полягає в тому, щоб дозволити тест-драйверу моделювати кілька партицій для вхідних топіків і, відповідно, давати змогу тестам перевіряти поведінку застосунку в умовах, ближчих до реальних. Це включає тестування стратегії розподілу ключів, коректності роботи з локальними state stores, а також сценаріїв, де порядок обробки в межах партиції критично важливий.
Реалізація такої можливості — нетривіальне завдання. Потрібно зберегти простоту API TopologyTestDriver, не перетворивши його на повноцінний, але важкий емулятор кластера Kafka. Водночас тестове середовище має достатньо точно відображати семантику багатопартиційних топіків, щоб тести дійсно виявляли проблеми, які можуть проявитися в продакшені.
Попри складність, напрямок зрозумілий: спільнота прагне зробити unit-тести в Kafka Streams не лише швидкими, а й реалістичними. Ініціатива Michelin — показовий приклад того, як великі користувачі не просто адаптують фреймворк під себе, а повертають свої напрацювання в ядро проєкту, роблячи інструмент кращим для всіх.
Коли Processor API стає єдиним вибором
Повертаючись до Processor API, варто окремо зупинитися на тому, чому деякі команди обирають його як єдиний інструмент, навіть маючи під рукою зручний DSL і потужні засоби тестування.
Одна з причин — бажання повністю контролювати поведінку застосунку в умовах високого навантаження. DSL, попри всі оптимізації, залишається шаром абстракції. Він приймає за розробника низку рішень щодо того, як саме будуть організовані внутрішні вузли топології, як будуть використовуватися state stores, як оброблятимуться певні крайові випадки. Для більшості застосунків це плюс: менше коду, менше можливостей помилитися. Але в системах, де кожен відсоток продуктивності має значення, а поведінка під навантаженням повинна бути абсолютно передбачуваною, такий «автоматизм» може сприйматися як ризик.
Інша причина — необхідність реалізувати патерни, які погано вкладаються в модель DSL. Наприклад, складні маршрутизаційні рішення, динамічне створення та керування кількома state stores, нетипові схеми повторної обробки або власні механізми дедуплікації. У таких випадках Processor API дає змогу будувати все «з нуля», не підлаштовуючись під обмеження високорівневих операторів.
Нарешті, Processor API часто стає природним вибором для команд, які вже мають глибоку експертизу в розподілених системах і не бояться працювати з низькорівневими деталями. Для них додатковий шар абстракції — це не стільки допомога, скільки ще один компонент, який потрібно розуміти, налагоджувати й враховувати при аналізі інцидентів.
Важливо, що Kafka Streams не нав’язує жодного з підходів як «правильний». Фреймворк надає інструменти, а вибір між DSL, Processor API та їхньою комбінацією залишається за командою. У цьому сенсі розвиток TopologyTestDriver, включно з майбутньою підтримкою багатопартиційності, однаково важливий для всіх трьох стилів: незалежно від рівня абстракції, розробники отримують можливість швидко й детально тестувати свою логіку.
Спільнота, якість PR і роль великих користувачів
За останні 12 місяців Kafka Streams пережив сплеск активності спільноти. Кількість зовнішніх PR і KIP-ів помітно зросла, настільки, що мейнтейнерам доводиться буквально «наздоганяти» чергу на рев’ю. На тлі загальної дискусії про роль AI в розробці коду неминуче виникає питання: як це вплинуло на якість внесків?
Картина виявляється менш драматичною, ніж можна було б очікувати. Так, трапляються поодинокі PR-и, які виглядають як «AI-слоп»: тисячі змінених файлів без зрозумілої мети, відсутність опису, ніякої реакції автора на коментарі. Такі запити очікувано закриваються. Але загалом якість внесків залишається високою, і за кодом часто неможливо однозначно сказати, чи був він згенерований за допомогою AI, чи написаний вручну.
Ключову роль тут відіграє культура рев’ю. Мейнтейнерів не цікавить, як саме був створений код; важливо, щоб він був зрозумілим, обґрунтованим, супроводжувався адекватним описом і проходив через звичні для open source процедури обговорення. У цьому сенсі рекомендації для потенційних контриб’юторів залишаються незмінними: готувати PR так, ніби ви «готували десерт для когось» — акуратно, з поясненнями, з повагою до часу тих, хто буде це «пробувати».
Приклад із header support для state stores добре ілюструє, як виглядає продуктивна взаємодія спільноти та «ядра» проєкту. Ініціатива була пріоритезована в Confluent, до неї залучили кількох інженерів, але до роботи долучилися й 4–5 людей із ширшої спільноти. У результаті в Kafka Streams 4.3 з’являються нові типи state stores, які зберігають не лише ключ і значення, а й часову мітку та заголовки, наближаючи модель зберігання до того, як працюють самі повідомлення в Kafka.
Цей приклад важливий і в контексті Processor API. Раніше розробники, яким потрібні були заголовки в стані, змушені були будувати власні типи значень, інкапсулюючи в них і payload, і метадані. Це призводило до додаткового шаблонного коду, ускладнювало міграції та робило логіку менш прозорою. Тепер значна частина цієї роботи перекладається на сам фреймворк, а Processor API залишається інструментом там, де дійсно потрібна повна кастомізація.
Висновок: контроль, зручність і швидкий зворотний зв’язок
Десятиріччя Kafka Streams показує, що зрілість фреймворку вимірюється не лише кількістю функцій, а й тим, наскільки добре він балансує між різними потребами розробників. Високорівневий DSL дає змогу швидко будувати топології, низькорівневий Processor API — тримати під контролем кожен запис і кожен байт у state stores, а TopologyTestDriver — перевіряти все це з мілісекундною затримкою, не піднімаючи кластера Kafka.
Обмеження, які ще вчора здавалися неминучими, сьогодні стають предметом KIP-ів. Однопартиційна модель TopologyTestDriver — один із таких прикладів. Ініціатива Michelin зробити тест-драйвер багатопартиційно обізнаним показує, як великі користувачі можуть впливати на еволюцію інструменту, від якого самі залежать.
На тлі зростання ролі AI в розробці, збільшення кількості контриб’юторів і розширення команди Kafka Streams у Confluent, фреймворк продовжує рухатися в бік більшої гнучкості та кращої підтримки життєвого циклу застосунків — від написання коду до його тестування й експлуатації. І в центрі цього руху залишаються ті самі принципи: прозорість, контроль і швидкий зворотний зв’язок для розробника.
Джерело
Confluent Developer Podcast — 10 Years of Kafka Streams with Matthias J. Sax | Ep. 32