Коли інфраструктурний дослідник і автор «Designing Data‑Intensive Applications» Мартін Клеппманн опинився в LinkedIn після продажу свого стартапу Rapportive, його продуктова команда з часом була розформована. Замість того, щоб шукати новий продукт усередині корпорації, він перейшов у стримінгову команду — до ядра інфраструктури, яка тоді тільки формувалася навколо Apache Kafka та фреймворку Samza. Саме цей перехід — від продуктового інженірингу до фундаментальних систем — став одним із ключових досвідів, що згодом лягли в основу першого видання його книжки про дата‑інтенсивні застосунки.
Kafka щойно була відкритою: LinkedIn тільки що вивів її в open source, і команда займалася тим, щоб перетворити внутрішній інструмент на універсальну платформу для потокової обробки даних. Паралельно Клеппманн, уже працюючи віддалено з Великої Британії, отримав від LinkedIn можливість витрачати приблизно половину свого часу на написання «Designing Data‑Intensive Applications» — рідкісний випадок, коли промислова інфраструктурна робота та глибока теоретична книга розвивалися практично синхронно.
Від продукту до інфраструктури: як розформована команда привела в стримінг
Rapportive, другий стартап Клеппманна, інтегрував соціальні профілі в Gmail через браузерне розширення. Після придбання LinkedIn невелика команда з п’яти людей деякий час працювала як напівнезалежний продукт усередині корпорації, а згодом запустила новий сервіс LinkedIn Intro. Попри те, що компанія дала команді велику свободу, продукт швидко закрили, а саму команду розпустили.
Для багатьох інженерів це означало б пошук іншої продуктової ролі. Клеппманн пішов іншим шляхом: він приєднався до стримінгової групи LinkedIn, яка займалася Kafka та побудовою системи потокової обробки даних. Це був різкий зсув фокусу — від Ruby on Rails, PostgreSQL і Redis, на яких працював Rapportive, до низькорівневої інфраструктури, що мала забезпечити роботу всієї соціальної мережі.
Саме в цей момент Kafka вийшла за межі внутрішнього проєкту: LinkedIn щойно відкрив її код, і технологія тільки починала свій шлях до статусу де-факто стандарту для стримінгових даних. Участь у цій роботі на ранньому етапі означала не просто підтримку готового продукту, а формування базових моделей того, як великі компанії інтегрують, зберігають і обробляють події в реальному часі.
Цей досвід виявився настільки тісно пов’язаним із темами майбутньої книги, що LinkedIn дозволив Клеппманну офіційно розділити час: приблизно половину робочого тижня він міг присвячувати «Designing Data‑Intensive Applications». У результаті книжка не стала абстрактною теорією — її концепції виростали безпосередньо з практики побудови стримінгової інфраструктури на масштабі LinkedIn.
Kafka як append‑only log: інтеграція даних замість зоопарку ETL
У LinkedIn Kafka замислювалася не як «черга повідомлень нового покоління», а як append‑only log — послідовний журнал подій, до якого лише дописують, але не змінюють уже записане. Така модель виявилася ключем до вирішення проблеми, яка переслідувала великі організації роками: як інтегрувати десятки джерел подій із безліччю споживачів, не перетворюючи інфраструктуру на хаотичну мережу одноразових інтеграцій.
У класичному підході кожна система, що генерує події — наприклад, веб‑фронтенд, мобільні клієнти, бекенд‑сервіси, — відправляє дані безпосередньо в конкретні цільові системи: аналітичні бази, сховища логів, системи рекомендацій. Кожна нова інтеграція означає ще один пайплайн, ще один ETL, ще один формат даних. З часом це перетворюється на «спагеті‑архітектуру», де будь‑яка зміна в одному місці тягне за собою каскадний ефект.
Kafka в LinkedIn запропонувала іншу модель. Усі події — кліки, перегляди, оновлення профілів, соціальні взаємодії — потрапляли спочатку в центральний лог. Цей лог ставав єдиним джерелом правди про те, що відбувається в системі. Далі вже будь‑які інші сервіси могли підписуватися на потрібні топіки, читати події у своєму темпі, перемотуватися назад, відтворювати історію.
У такій архітектурі Kafka фактично виконувала роль «центральної нервової системи» даних. Замість того, щоб кожен організм (сервіс) будував власні нервові закінчення до кожного іншого, усі сигнали проходили через спільний хребет — append‑only log. Це радикально спрощувало інтеграцію: нова система просто підключалася до вже існуючого потоку подій, не змінюючи джерела.
Ключовим було саме append‑only представлення. Події не перезаписувалися, а лише додавалися в кінець журналу. Це дозволяло:
по‑перше, відтворювати стан будь‑якої системи, програвши події з нуля до потрібного моменту;
по‑друге, підключати нові споживачі заднім числом, не втрачаючи історичних даних;
по‑третє, будувати на одному й тому самому потоці як онлайн‑сервіси, так і аналітичні пайплайни.
Саме така інтерпретація Kafka як журналу подій, а не просто черги, стала одним із центральних концептів, які згодом потрапили в «Designing Data‑Intensive Applications».
Від Kafka до Samza: як будувалися stateful стримінгові пайплайни
Kafka сама по собі вирішувала проблему транспорту та зберігання подій, але не відповідала на питання, як саме їх обробляти в реальному часі. Для цього в LinkedIn розвивали Samza — фреймворк потокової обробки, побудований поверх Kafka.
Samza пропонував модель, у якій розробник описує обробники подій, а фреймворк бере на себе розподіл навантаження, fault tolerance і роботу зі станом. На відміну від простих стримінгових бібліотек, які працюють із подіями як із незалежними повідомленнями, Samza був орієнтований на stateful обробку — коли результат залежить не лише від поточного повідомлення, а й від накопиченого стану.
Це критично для реальних бізнес‑задач: рекомендаційні системи, антифрод, персоналізація, аналітика в реальному часі — усі вони потребують збереження проміжних результатів, агрегацій, вікон часу. У зв’язці Kafka + Samza Kafka надавала надійний, відтворюваний потік подій, а Samza — механізм перетворення цього потоку в корисні, оновлювані в реальному часі представлення даних.
У LinkedIn така стримінгова інфраструктура живила не лише онлайн‑функціональність, а й аналітичні та ML‑навантаження. Kafka слугувала джерелом даних для дацаверхаузу та Hadoop‑кластерів, на яких будувалися моделі машинного навчання й аналітичні звіти. Події, що проходили через Kafka, потрапляли в Hadoop для глибокої офлайн‑обробки, а результати могли повертатися в онлайн‑сервіси, знову ж таки через стримінгові канали.
Таким чином, Kafka і Samza стали не просто інструментами для логування чи черг, а основою цілісної архітектури, де онлайн‑і офлайн‑світ даних були пов’язані єдиною подієвою моделлю. Саме ця ідея — розглядати дані як потоки подій, а не лише як статики в базі — стала однією з найвпливовіших у сучасних дата‑системах.
Централізований лог і нові компроміси: доступність проти складності
Коли стримінгова інфраструктура стає «нервовою системою» компанії, питання надійності виходять на перший план. Від того, як спроєктовано Kafka‑кластери й обробку поверх них, залежить не лише аналітика, а й безпосередньо користувацький досвід: рекомендації, фіди, нотифікації.
У цьому контексті особливо гостро постає питання архітектурних компромісів: чи варто будувати multi‑zone, multi‑region або навіть multi‑cloud конфігурації? Клеппманн підкреслює, що такі рішення — це не просто «галочки» в архітектурній діаграмі, а фундаментальний вибір між різними видами ризиків і витрат.
З одного боку, рознесення системи по кількох зонах доступності або регіонах зменшує ризик повного даунтайму через збій у дата‑центрі чи регіоні. Multi‑cloud додає ще один рівень захисту — від проблем конкретного провайдера. Для інфраструктури, яка є центральним вузлом усіх даних, це виглядає привабливо: падіння Kafka‑кластера в монорегіональній конфігурації може паралізувати значну частину бізнесу.
З іншого боку, кожен крок до більш розподіленої архітектури приносить із собою не лише обчислювальні накладні витрати, а й людські. Реплікація даних між регіонами, узгодженість, latency, складні сценарії відмов — усе це збільшує як вартість інфраструктури, так і складність її проєктування та експлуатації.
Клеппманн пропонує дивитися на це як на баланс між:
ризиком недоступності, який ви готові прийняти;
обчислювальними накладними витратами, пов’язаними з реплікацією, надлишковими ресурсами, складнішими протоколами;
людськими витратами — часом і компетенціями команд, які мають спроєктувати, реалізувати й підтримувати таку систему.
У випадку Kafka та Samza на масштабі LinkedIn це означало, що питання «чи робити multi‑region?» не могло мати універсальної відповіді. Для одних потоків подій, критичних до доступності, складніша, географічно розподілена архітектура могла бути виправданою. Для інших — простіший, але менш захищений варіант виявлявся раціональнішим, якщо враховувати повну вартість володіння, включно з людським фактором.
Цей підхід до компромісів — не як до суто технічних, а як до бізнес‑рішень із чітко вираженими витратами й ризиками — став однією з характерних рис мислення, яке Клеппманн розвиває і в своїй книзі, і в подальших дослідженнях.
Хмара, стримінг і зміна парадигми масштабування
Поява хмарних провайдерів змінила те, як компанії масштабують бекенд‑системи. Якщо раніше збільшення навантаження означало закупівлю нових серверів, планування capacity на місяці вперед і складні міграції, то з хмарою масштабування стало значно еластичнішим. Але в поєднанні зі стримінговими системами на кшталт Kafka це призвело до ще глибшої зміни парадигми.
У традиційній моделі дані часто сприймалися як щось статичне: таблиці в базі, періодичні дампи в дацаверхауз, нічні batch‑джоби. Масштабування означало збільшення потужності цих сховищ і обчислювальних кластерів. Стримінгова модель, яку розвивали в LinkedIn, змістила фокус на постійний потік подій, що ніколи не зупиняється.
У хмарному середовищі це відкриває можливість масштабувати не лише сховища, а й самі обробники подій: додавати нові інстанси стримінгових застосунків, розподіляти партиції Kafka між ними, змінювати топологію пайплайнів без зупинки системи. Але водночас це загострює питання архітектурних компромісів: кожен додатковий рівень розподілу — між зонами, регіонами, хмарами — збільшує складність як коду, так і операцій.
У цьому сенсі досвід LinkedIn із Kafka та Samza став одним із перших великих прикладів того, як хмара й стримінг разом змінюють саме поняття масштабування. Йдеться вже не лише про «більше серверів», а про побудову систем, де дані постійно рухаються, а обробка відбувається максимально близько до цього руху — у реальному часі, із можливістю відтворення історії за потреби.
Ця модель сьогодні здається майже очевидною для великих технологічних компаній, але на момент, коли Клеппманн працював у стримінговій команді LinkedIn, вона ще тільки кристалізувалася. Саме тому його участь у розвитку Kafka та Samza на ранньому етапі виявилася настільки впливовою для формування загальної картини сучасних дата‑інтенсивних систем.
Книга, що писалася разом із інфраструктурою
Особливість історії Клеппманна полягає в тому, що «Designing Data‑Intensive Applications» не була написана «після» практичного досвіду — вона створювалася паралельно з роботою над реальною інфраструктурою LinkedIn. Компанія дозволила йому офіційно витрачати близько 50% робочого часу на книгу, поки решту він присвячував Kafka, Samza та стримінговим пайплайнам.
Це означало, що концепції, які потрапляли в перше видання, проходили постійну перевірку реальністю. Ідеї про журнали подій, стримінгову обробку, інтеграцію онлайн‑ і офлайн‑світів даних, компроміси між доступністю й складністю — усе це не було абстрактною теорією, а відображенням конкретних рішень, які доводилося приймати в системі масштабу LinkedIn.
Пізніше, у другому, суттєво оновленому виданні, яке вийшло приблизно через дев’ять років після першого, частина старих технологій, на кшталт MapReduce, зникла з фокусу, натомість з’явилося більше матеріалу про системи, що підтримують AI‑навантаження, включно з векторними індексами. Але фундаментальна ідея — розглядати дані як потоки подій, а інфраструктуру як набір компромісів між надійністю, продуктивністю та складністю — залишилася незмінною. І саме досвід роботи з Kafka та Samza в LinkedIn багато в чому сформував цю оптику.
Висновок: стримінг як норма і ціна складності
Історія переходу Мартіна Клеппманна з продуктового інженірингу в Rapportive до інфраструктурної ролі в стримінговій команді LinkedIn показує, як швидко змінилася парадигма роботи з даними за останнє десятиліття. Kafka, що починалася як внутрішній журнал подій, перетворилася на центральну нервову систему даних, яка живить як онлайн‑сервіси, так і аналітику та машинне навчання. Samza дав модель stateful обробки в реальному часі, побудовану поверх цього журналу.
Разом вони сформували архітектуру, де дані сприймаються як безперервний потік, а не як статичні таблиці, а масштабування означає не лише додавання ресурсів, а й продуманий вибір між доступністю, продуктивністю та операційною складністю. Рішення про multi‑zone, multi‑region чи multi‑cloud конфігурації в такій архітектурі стають не технічними «опціями», а бізнес‑компромісами з чітко вимірюваними ризиками та витратами.
Те, що LinkedIn дозволив Клеппманну поєднати роботу над цією інфраструктурою з написанням «Designing Data‑Intensive Applications», зробило книгу унікальною: вона стала не лише описом того, як «має бути», а й рефлексією над тим, як великі системи насправді будуються, ламаються й еволюціонують у світі хмари та стримінгу. І саме тому сьогодні, коли Kafka‑подібні журнали подій і стримінгові пайплайни стали нормою для компаній, що працюють на хмарному масштабі, ці ідеї залишаються актуальними — як нагадування про те, що за кожною додатковою дев’яткою доступності стоїть не лише новий кластер, а й додатковий шар людської та технічної складності.
Джерело
Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer