Коли сьогодні говорять про Apache Kafka, зазвичай мають на увазі зрілу екосистему, керовані кластери в хмарі та відпрацьовані патерни. Але для Матео Рохаса з Кіто, Еквадор, знайомство з Kafka почалося зовсім в інших умовах: у 20 років він увійшов в індустрію й одразу опинився в команді, яка будувала систему управління реальними грошима на ще «сирих» Kafka Streams. Сьогодні, у 28, він працює в компанії LittleHorse над workflow‑рушієм поверх Kafka, має близько восьми років досвіду в розробці, шість із яких — у консалтингу, і при цьому відмовляється називати себе «ветераном Kafka».
Історія його кар’єрного старту — це не просто біографічний епізод. Це концентрований зріз того, як виглядало впровадження стрімінгових технологій у фінансових системах у момент, коли інструменти ще не встигли наздогнати амбіції інженерів. І водночас — пояснення, чому навіть досвідчені фахівці обережно ставляться до тверджень, що «Kafka ми вже знаємо».
Старт кар’єри з глибокого кінця басейну
Більшість розробників починають з CRUD‑додатків, внутрішніх панелей чи невеликих сервісів. Для Матео точкою входу стала подія, яка визначила його подальший професійний фокус: перший серйозний проєкт одразу був пов’язаний з Apache Kafka, причому не як допоміжною шиною подій, а як центральним елементом фінансової платформи.
Він почав кар’єру приблизно у 20 років, і «щасливий збіг обставин» полягав у тому, що старт припав саме на Kafka. Цей «щасливий» момент, як він сам визнає, був і джерелом змішаних почуттів: технологія вже існувала, але багато речей, які сьогодні сприймаються як базові можливості, тоді ще або не були реалізовані, або тільки з’являлися. Йдеться про період близько 2018 року, коли Kafka Streams була ще відносно молодою (framework стартував у 2016‑му), а патерни її використання в складних доменах лише формувалися.
До цього часу Матео встиг попрацювати в різних компаніях і проєктах, переважно як консультант. Близько шести років консалтингу в стрімінгових і розподілених системах означають постійне занурення в чужі архітектури, спадковий код і нетривіальні сценарії використання Kafka. Але навіть із цим багажем він підкреслює: Kafka настільки багатогранна й динамічна, що відчуття «я вже все про неї знаю» просто не виникає.
Це важливий контраст до поширеного враження, що кілька років роботи з Kafka автоматично роблять інженера «експертом». У випадку Матео вісім років досвіду не перетворюються на самовпевненість — радше на усвідомлення глибини екосистеми.
Реальні гроші на ще незрілій технології
Перший великий Kafka‑проєкт Матео — це платформа управління полісами з реальними грошима, побудована на Kafka Streams приблизно у 2018 році. Суть бізнесу була простою для користувача, але складною для інженерів: клієнт заходить на веб‑сторінку, купує ануїтетний поліс, наприклад, на три роки під 3% річних, вкладаючи $10 000, і очікує, що гроші почнуть нараховувати відсотки, коли поліс буде активовано.
За цим простим сценарієм стояла жорстка реальність фінансового домену. Помилка в обробці подій означала не абстрактний «баг у логіці», а прямий вплив на реальні кошти клієнтів: подвійне нарахування відсотків, пропущені транзакції, некоректні стани полісів. Для молодого розробника це означало навчання в умовах, де ціна помилки відчутна й вимірюється грошима, а не лише SLA.
Особливість моменту полягала в тому, що команда працювала з Kafka Streams у фазі, коли фреймворк ще не мав багатьох «комфортних» можливостей. Наприклад, exactly‑once semantics для обробки повідомлень тоді ще не були доступні. Для системи, яка керує грошима, це створювало фундаментальну проблему: неможливо допустити, щоб через повторну доставку повідомлення або збої в коміті офсетів система двічі запустила процес нарахування відсотків за одним і тим самим полісом.
Додатковий рівень складності додавав інфраструктурний контекст. Керовані сервіси на кшталт Confluent Cloud чи AWS MSK ще не були доступні для цієї команди, тож Kafka доводилося розгортати й підтримувати самостійно, у власному Kubernetes‑кластері. Це означало, що кожна проблема — від конфігурації брокерів до відмовостійкості — вирішувалася силами тієї ж команди, яка паралельно будувала складну бізнес‑логіку на Streams.
Інакше кажучи, Матео опинився в ситуації, коли потрібно було одночасно розбиратися в розподіленій інфраструктурі, новому стрімінговому фреймворку й тонкощах фінансового домену. Для кар’єрного старту це радше «глибокий кінець басейну», ніж комфортний вхід у професію.
Як високі ставки формують підхід до розподілених систем
Робота над грошовими потоками в умовах технологічної незрілості неминуче впливає на те, як інженер надалі мислить про розподілені системи. У випадку Матео цей вплив проявляється в кількох вимірах.
По‑перше, з’являється дуже конкретне відчуття ризику. Коли система керує полісами, де кожен крок — від перевірки клієнта до нарахування відсотків — має фінансовий наслідок, будь‑яка абстракція типу «event‑driven» перестає бути модною концепцією й стає джерелом потенційних помилок. Наприклад, відсутність exactly‑once змусила команду будувати власні механізми дедуплікації поверх Kafka Streams, використовуючи KTable як сховище оброблених ідентифікаторів повідомлень. Це не просто технічний трюк, а реакція на доменну вимогу: гроші не пробачають дублювання подій.
По‑друге, ранній досвід з Kafka Streams у ролі «оркестратора всього» показав, наскільки небезпечно намагатися розв’язати всі задачі одним інструментом. У тій першій системі команда одночасно експериментувала з різними підходами до подій: від простих нотифікацій на кшталт «policy created» до event‑carried state transfer і елементів event sourcing. У підсумку в різних мікросервісах співіснували різні патерни, що ускладнювало як розуміння системи, так і її еволюцію.
Цей досвід сформував у Матео більш стриманий погляд на роль Kafka Streams у складних доменах. Згодом він приходить до ідеї, що для оркестрації складних бізнес‑процесів доцільніше використовувати спеціалізований workflow‑рушій, а Streams — для трансформації даних, аналітики чи окремих обчислювальних задач. Це не заперечення можливостей Streams, а радше визнання того, що різні інструменти краще підходять для різних рівнів відповідальності.
По‑третє, робота з реальними грошима на ще незрілих інструментах загострює увагу до спостережуваності й дебагінгу. Наприклад, спроби використовувати складні join‑операції в Kafka Streams для об’єднання кількох потоків подій (про це детальніше йдеться в іншій частині серії) виявилися болючими саме через складність діагностики: важко зрозуміти, чи подія ще в межах вікна, чи вже «випала», чи збережена в KTable, і чому конкретний join не відбувся. Для системи, де від цього залежить активація полісу, така непрозорість стає серйозним операційним ризиком.
Усе це разом формує те, що можна назвати «обережним прагматизмом» у підході до розподілених систем. Замість того щоб захоплюватися новими можливостями фреймворків, Матео дивиться на них через призму запитання: що станеться з реальними грошима, якщо ця абстракція дасть збій?
Чому навіть після восьми років Kafka не здається вивченою
Попри те, що Матео працює з Kafka практично від початку своєї кар’єри, він принципово не називає себе «ветераном». Аргументація проста: Kafka — це не один продукт, а ціла екосистема, яка постійно розширюється й ускладнюється. Зміни відбуваються як на рівні ядра (брокери, протоколи, реплікація), так і на рівні клієнтських бібліотек, стрімінгових фреймворків, інтеграційних інструментів.
Такий погляд контрастує з типовою для індустрії тенденцією швидко присвоювати собі статус «експерта» після кількох успішних проєктів. У випадку Kafka, особливо в контексті фінансових систем, подібна самовпевненість може бути небезпечною. Кожен новий реліз, кожен новий патерн використання — це не просто «ще одна фіча», а потенційна зміна в тому, як система поводиться під навантаженням, у разі збоїв чи при інтеграції з іншими сервісами.
Досвід Матео як консультанта додатково підсилює це відчуття. Робота з різними компаніями й доменами показує, наскільки по‑різному Kafka може бути вплетена в архітектуру: від простих черг подій до центрального джерела істини для критичних бізнес‑процесів. Кожен такий сценарій висуває свої вимоги до конфігурації, безпеки, моделювання подій і гарантій доставки.
У підсумку формується парадоксальна, але здорова позиція: вісім років щільної роботи з Kafka — це достатньо, щоб розуміти її силу й обмеження, але недостатньо, щоб вважати тему «закритою». Особливо, якщо згадати, що за цей час екосистема встигла пройти шлях від самокерованих кластерів у Kubernetes до повноцінних керованих сервісів, а Kafka Streams — від перших версій без exactly‑once до зріліших реалізацій з розвиненими можливостями.
Від хаосу ранніх Streams до workflow‑рушія на Kafka
Сьогодні Матео працює в компанії LittleHorse, де команда будує workflow‑рушій поверх Kafka. Це логічне продовження його кар’єрної траєкторії: від спроб використовувати Kafka Streams як універсальний інструмент для оркестрації всього — до створення спеціалізованого шару, який бере на себе саме оркестрацію, залишаючи Kafka ролі транспортного й подієвого фундаменту.
Цей перехід показовий не лише для особистої історії, а й для еволюції підходів в індустрії. Якщо на початку стрімінгової ери багато команд намагалися «натягнути» Kafka Streams на всі задачі — від обробки подій до складних бізнес‑процесів, — то сьогодні дедалі частіше з’являються рішення, які розділяють відповідальність. Workflow‑рушії беруть на себе моделювання й виконання процесів, тоді як Kafka забезпечує надійну доставку й зберігання подій.
Для Матео цей рух — не теоретична дискусія, а практичний висновок із першого великого проєкту. Тоді, в 2018‑му, команда намагалася оркеструвати все через Streams, включно з перевірками KYC, AML, підтвердженням банківських переказів і активацією полісів. Сьогодні він дивиться на це як на приклад того, як не варто будувати систему цілком: Streams залишаються потужним інструментом, але не обов’язково мають бути центром усієї бізнес‑логіки.
Цей досвід також підживлює обережність у відповідях на «вічні» питання на кшталт того, чи має Kafka бути джерелом істини для системи. У фінансових доменах, де дані мають зберігатися довго, бути захищеними й водночас доступними для відтворення стану, спокуса зробити Kafka єдиним truth‑layer дуже велика. Але разом із нею приходять питання про шифрування, регуляторні вимоги, управління схемами й еволюцію подій. Для інженера, який починав із реальних грошових потоків на ще незрілих Streams, ці питання ніколи не залишаються суто теоретичними.
Висновок: кар’єра, сформована під тиском реальних грошей
Історія Матео Рохаса — це приклад того, як ранній досвід у високоризикових системах формує інженерне мислення. Почати кар’єру в 20 років із побудови платформи, де помилка напряму впливає на гроші клієнтів, причому на базі технології, яка ще не встигла подорослішати, — означає навчатися швидко й болісно. Але саме цей досвід закладає фундамент для подальшої роботи з розподіленими системами: розуміння цінності гарантій доставки, обережне ставлення до складних абстракцій, прагнення розділяти відповідальність між інструментами.
Сьогодні, маючи близько восьми років досвіду в індустрії, шість із яких — у консалтингу, і працюючи над workflow‑рушієм на Kafka в LittleHorse, Матео не претендує на статус «ветерана Kafka». І в цьому є певний маркер зрілості: чим глибше занурення в екосистему, тим очевиднішою стає її складність і динамічність.
Для інженерів, які лише починають шлях у стрімінгових технологіях, ця історія може бути корисним орієнтиром. Вона показує, що робота з Kafka — це не лише про черги й топіки, а про відповідальність за реальні бізнес‑наслідки. І що іноді найцінніший досвід народжується саме тоді, коли технологія ще не встигає за амбіціями, а система працює з грошима, які не пробачають помилок.
Джерело
Building Banking Systems with Kafka Streams with Mateo Rojas | Ep. 28 | Confluent Developer Podcast