Мартин Клеппман сьогодні відомий насамперед як автор «Designing Data-Intensive Applications» — книжки, яку багато бекенд‑інженерів вважають настільною. Але до того, як перейти в академію й систематизувати досвід у теорії розподілених систем, він кілька років будував дуже приземлені продукти: сервіс автоматизованого тестування Go Test It та Gmail‑розширення Rapportive, яке згодом купив LinkedIn. Саме ці практичні спроби — з реальними користувачами, обмеженим бюджетом і тиском інвесторів — сформували його погляд на те, як мають працювати дані, інфраструктура й команди.
Ця історія — не про книжку і не про Kafka, а про те, як два невеликі стартапи, один майже повністю бутстреплений, інший — з Y Combinator і подальшим продажем LinkedIn, навчили Клеппмана мислити системами, а не лише кодом.
Go Test It: коли технічно все працює, але бізнес — ні
Перший стартап Клеппмана, Go Test It, народився приблизно у 2008 році — в епоху, коли веб‑розробники масово страждали від несумісності браузерів. Internet Explorer залишався домінантним, Chrome тільки з’явився, а JavaScript поводився по‑різному на кожній платформі. Ідея здавалася очевидною: дати розробникам сервіс, який автоматизує клікання по сайту в різних браузерах і перевіряє, що все працює однаково.
Go Test It був побудований поверх Selenium — відкритого проєкту, який і сьогодні є стандартом для браузерної автоматизації. Користувачі мали писати скрипти, що імітують дії реального користувача: переходи по сторінках, кліки, введення тексту. Сервіс запускав ці сценарії у різних браузерах і середовищах, а розробники отримували результат без необхідності самостійно піднімати зоопарк віртуальних машин.
Технічно продукт працював. Проблема була в іншому: у звичках команд і в економіці.
Багато веб‑розробників погоджувалися, що кросбраузерне тестування потрібне. Але між «так, це важливо» і реальним впровадженням у процес — прірва. Потрібно було змінювати робочі практики, вкладати час у написання тестів, інтегрувати сервіс у CI‑пайплайни. Для невеликих команд це часто виглядало як надто велика інвестиція «на потім», особливо коли дедлайни підтискають, а бізнес вимагає фічі вже сьогодні.
Go Test It опинився в незручній ніші: проблема реальна, рішення технічно коректне, але adoption повільний і болючий. На ринку з’явилися й інші гравці, зокрема Sauce Labs, які змогли побудувати бізнес на подібній моделі, але навіть для них це був «повільний» ринок, без вибухового зростання.
Для Клеппмана це стало першим уроком: інженерна елегантність і навіть очевидна корисність не гарантують життєздатності бізнесу. Сервіс, який вимагає від команд змінювати процеси, завжди стикається з інерцією — і ця інерція часто сильніша за технічну логіку.
Бутстреп замість венчурного капіталу: як виглядає стартап без великого чека
Фінансова модель Go Test It була далекою від класичного венчурного сценарію. Стартап був переважно бутстреплений: Клеппман займався консалтингом, а зароблені гроші спрямовував на розробку продукту. До команди долучилися друзі, яких вдавалося наймати «на дешево», а зовнішні інвестиції обмежилися невеликою сумою ангельського капіталу.
Це створювало дуже специфічний режим роботи. З одного боку, не було тиску фондів, вимог до агресивного зростання чи миттєвого масштабування. З іншого — не було й фінансової «подушки», яка дозволила б довго експериментувати з моделлю монетизації, маркетингом чи зміною позиціонування.
Бутстрепований стартап змушений бути надзвичайно ощадливим у всьому: від технічних рішень до найму. Кожна година розробки має прямий грошовий еквівалент, бо оплачується з консалтингових доходів. Кожна фіча — це вибір між «часом, який приносить гроші зараз», і «часом, який, можливо, принесе гроші потім».
Go Test It у підсумку «не полетів» у великому сенсі. Але саме через цю модель Клеппман отримав досвід, який пізніше стане важливим для його погляду на системи: як будувати продукт, коли ресурси обмежені, як обирати технології, які можна підтримувати невеликою командою, і як реальні користувачі реагують на інструменти, що вимагають змін у процесах.
Цей досвід контрастує з подальшою історією Rapportive, де траєкторія була зовсім іншою: швидке зростання, Y Combinator, переїзд у Сан‑Франциско й продаж LinkedIn.
Rapportive: соціальний граф у вашій пошті
Другий стартап Клеппмана, Rapportive, з’явився близько 2010 року і працював у зовсім іншому просторі — на перетині електронної пошти та соціальних мереж. Ідея була простою й дуже конкретною: коли ви отримуєте лист від людини, яку не знаєте, Gmail показує лише адресу й, можливо, ім’я. Rapportive додавав до цього контекст.
Команда створила браузерне розширення, яке змінювало веб‑інтерфейс Gmail. Праворуч від листа з’являлася панель із «соціальним профілем» відправника: фотографія, посада з LinkedIn, останні твіти з Twitter, недавні пости з Facebook — усе, що вдавалося знайти за адресою електронної пошти. Фактично Rapportive збирав розрізнені фрагменти соціальних даних і перетворював їх на компактну картку, прив’язану до конкретного листа.
Це вирішувало дуже прикладну задачу: зрозуміти, хто перед вами — рекрутер, потенційний клієнт, журналіст, колега з іншої компанії. Для людей, які живуть у пошті — сейлзів, фаундерів, рекрутерів, — такий контекст миттєво додавав цінності.
На відміну від Go Test It, Rapportive не вимагав від користувача змінювати процеси. Достатньо було встановити розширення — і користь ставала очевидною вже з першими листами. Цей низький бар’єр входу й чітка, відчутна цінність зробили продукт популярним досить швидко.
Технічно це була непроста задача: потрібно було інтегруватися з Gmail, акуратно «перемальовуючи» його інтерфейс, не ламаючи функціональність і не викликаючи підозр у користувачів. Але саме така інтеграція — без вимоги до змін поведінки — стала ключем до adoption. Це ще один урок, який пізніше відчутно проглядається в підході Клеппмана до систем: найкращі інструменти — ті, що вбудовуються в існуючі потоки роботи, а не вимагають їх ламати.
Від Лондона до Кремнієвої долини: Y Combinator і маленька команда, яку купив LinkedIn
Rapportive став для Клеппмана квитком у світ класичного стартап‑наративу початку 2010‑х. Компанія потрапила в один із ранніх наборів Y Combinator — у той період, коли акселератор уже мав репутацію, але залишався відносно невеликим і експериментальним.
Для участі команда переїхала з Великої Британії до Сан‑Франциско. Спочатку це були кілька місяців програми, потім — отримання робочих віз і вже постійна присутність у Bay Area. Для фаундерів, які до того будували бізнес у Великій Британії, це означало потрапляння в екосистему, де доступ до інвесторів, партнерів і користувачів був набагато щільнішим. Мережа контактів нарощувалася буквально через ланцюжок знайомств: знайомі знайомих, інтро, зустрічі — і за відносно короткий час команда стала частиною місцевої сцени.
Попри популярність продукту, фінансова траєкторія була не такою прямолінійною. Rapportive ріс, але не настільки агресивно, щоб без проблем залучити великий новий раунд. Спроби знайти стійку модель монетизації не дали швидкого результату, а гроші поступово закінчувалися. Команда опинилася в класичній для стартапів «сірої зоні»: користувачі є, продукт люблять, але інвестори хочуть або більшого зростання, або чіткішої бізнес‑моделі.
У цей момент з’явився варіант продажу. Близько 2012 року LinkedIn придбав Rapportive, коли в компанії працювало всього близько п’яти людей. Це був типовий «acqui-hire плюс продукт»: невелика, але сфокусована команда, яка вміє працювати з соціальними даними й електронною поштою, і продукт, що добре вписується в бачення LinkedIn як професійної соціальної мережі.
Важливий нюанс — візові обмеження. Засновники не могли просто «урізати собі зарплату й дотягнути до наступного раунду»: це порушило б умови їхніх робочих віз у США. Тож простір для маневру був обмежений. У такій ситуації продаж компанії став радше «найменш поганим» варіантом, ніж реалізацією мрії про екзит. Але заднім числом Клеппман оцінює результат як успішний для всіх сторін: команда отримала стабільність і можливість продовжити роботу над схожими ідеями вже в масштабі великої платформи.
Цей досвід показав ще одну сторону реальних систем: технічні рішення й архітектура завжди вплетені в юридичні, фінансові й організаційні обмеження. Візи, burn rate, переговорна позиція на M&A — усе це так само формує траєкторію продукту, як і вибір бази даних.
Життя всередині LinkedIn: свобода, експерименти й закритий LinkedIn Intro
Після придбання LinkedIn не розчинив Rapportive у великій організації. Команді дозволили певний час працювати майже як незалежному підрозділу всередині компанії. Вони продовжили розвивати свої ідеї навколо інтеграції соціального контексту в електронну пошту.
Оригінальне розширення для Gmail фактично перевели в режим підтримки: воно залишалося доступним, але не було в центрі уваги. Натомість команда зосередилася на новому продукті, який згодом вийшов під брендом LinkedIn Intro.
LinkedIn Intro був логічним продовженням ідеї Rapportive, але вже в тіснішій зв’язці з екосистемою LinkedIn. Команда отримала значну автономію: змогла спроєктувати продукт, реалізувати його й вивести на ринок. Для великої корпорації це нетипово високий рівень довіри до невеликої придбаної команди.
Однак ринковий прийом виявився складним. Продукт отримав «дивну» реакцію, і невдовзі після запуску його закрили. Попри це, Клеппман оцінює досвід позитивно: LinkedIn дав можливість спробувати, не караючи команду за невдачу, і підтримував її протягом усього циклу — від ідеї до закриття.
Після згортання LinkedIn Intro команда була розформована. Для Клеппмана це стало поворотним моментом: далі він перейшов у внутрішню команду LinkedIn, яка займалася потоковою обробкою даних. Саме там він працюватиме з Kafka й Samza — досвідом, що згодом ляже в основу багатьох ідей «Designing Data-Intensive Applications». Але це вже інша частина історії, яку розкривають окремі розмови про стрімінг і масштабування.
У контексті Rapportive важливіше інше: як виглядає шлях невеликої команди, що потрапляє в екосистему великої платформи, отримує автономію, будує продукт, який не злітає, і все одно виходить із цього досвіду з новим розумінням того, як працюють великі системи — технічно й організаційно.
Ruby on Rails, PostgreSQL і граф на реляційній базі
На тлі всіх цих бізнес‑поворотів технічна сторона Rapportive виглядала, на перший погляд, досить буденно. Бекенд був написаний на Ruby on Rails, із PostgreSQL як основною базою даних і Redis як допоміжним компонентом. Жодних модних на той час NoSQL‑екзотик, жодних спеціалізованих графових баз.
Але саме в цій «звичайності» ховається цікавий інженерний момент. Rapportive працював із соціальними даними: зв’язки між людьми, профілі, джерела інформації з різних сервісів. Природна модель для таких даних — граф: вузли (користувачі, акаунти, профілі) і ребра (зв’язки між ними). Замість того щоб переходити на спеціалізовану графову СУБД, Клеппман фактично побудував графоподібну модель поверх PostgreSQL.
Це означало, що логіка графа — зв’язки, переходи, агрегації — реалізовувалася на рівні схеми й запитів у реляційній базі. PostgreSQL виступав як надійний, добре відомий «двигун збереження», а графова семантика жила в застосунку й структурі таблиць. Redis додавав швидкість там, де потрібні були кеші чи швидкий доступ до часто використовуваних даних.
Такий підхід добре ілюструє прагматичний стиль, який пізніше стане характерним для «Designing Data-Intensive Applications». Замість того щоб гнатися за спеціалізованими технологіями, команда обрала стабільні, перевірені інструменти й адаптувала їх під свої потреби. Це знижувало операційні ризики: Rails + PostgreSQL — стек, для якого легко знайти розробників, документацію, best practices. У невеликій команді з п’яти людей це критично.
Фактично Rapportive став для Клеппмана практичним полігоном, де він відчув на собі ключові компроміси, про які пізніше писатиме як про загальні принципи:
- краще добре зрозумілий інструмент, трохи «натягнутий» під задачу, ніж ідеально відповідна, але малопоширена технологія з високими операційними витратами;
- модель даних можна будувати поверх реляційної бази, якщо чітко розуміти, як саме застосунок працює з цими даними;
- простота стеку — це не лише про швидкий старт, а й про здатність маленької команди підтримувати систему в продакшені.
Цей досвід роботи з реальними навантаженнями, реальними користувачами й дуже обмеженими ресурсами став противагою до академічних моделей. Саме він зробив подальшу книжку Клеппмана не теоретичним трактатом, а практичним путівником по компромісах, з якими стикаються інженери в живих системах.
Висновок: як маленькі продукти формують велике мислення про системи
Шлях Мартина Клеппмана від Go Test It до Rapportive і далі в LinkedIn — це історія про те, як конкретні, часто болючі інженерні й бізнесові рішення формують погляд на системи набагато сильніше, ніж абстрактні моделі.
Go Test It показав, що технічно правильний продукт може не злетіти, якщо він вимагає від команд змінювати процеси й вкладати час у те, що не дає миттєвої віддачі. Бутстреп змусив рахувати кожну годину розробки й обирати технології, які можна підтримувати без армії інженерів.
Rapportive продемонстрував силу продуктів, які вбудовуються в існуючі потоки роботи й одразу дають відчутну користь. Y Combinator і переїзд у Сан‑Франциско відкрили доступ до іншої екосистеми, але водночас показали, як візові й фінансові обмеження можуть визначати долю компанії не менше, ніж технічні рішення.
Продаж LinkedIn і робота над LinkedIn Intro дали досвід того, як маленька команда може зберігати автономію всередині великої платформи, будувати амбітний продукт, провалюватися з ним — і все одно виходити з цього сильнішою. А бекенд Rapportive на Rails, PostgreSQL і Redis став прикладом того, як графоподібні моделі можна реалізувати поверх реляційних баз, якщо мислити даними й компромісами, а не модними ярликами.
Усе це — фундамент, на якому пізніше з’явиться «Designing Data-Intensive Applications». Але навіть безвідносно до книжки історія цих стартапів показує: глибоке розуміння розподілених систем народжується не лише в лабораторіях і на конференціях, а й у маленьких офісах, де п’ятеро людей намагаються змусити Rails‑додаток на PostgreSQL тягнути соціальний граф мільйонів користувачів, коли гроші на рахунку тануть, а візові обмеження не дозволяють просто «переждати важкі часи».
Джерело
Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer