Пару недель назад проводили в сообществе эфир по system design собесу в Яндекс. Собрал для тебя самое важное, чтобы ты хорошо прошел секцию

1️⃣ Проектирование может служить чит кодом, чтобы получить по верху вилки

В Яндексе каждая секцию имеет свой разброс по грейдам:
🔵Алгосы: стажер, джун, миддл, миддл+
🔵Проектирование: Не нанимать, middle+, senior, senior+

Да, грейды в Яндексе идут от стажер до эксперта. Примерно такая градация:
🔵Стажер
🔵Джун
🔵Миддл
🔵Миддл+
🔵Сеньор
🔵Сеньор+
🔵Эксперт

Если ты валишь проектирование, твой потолочный Грейд — middle+. Ты можешь подумать: ну и ладно, а если пройду проектирование на middle+, будет тот же грейд. Какая разница, завалил или нет 🙂

А разница вот в чем: с проектированием на middle+ тебе с бОльшей вероятностью дадут верх вилки, welcome bonus, а количество команд на финалах, которые захотят с тобой пообщаться, значительно увеличится. Так что тебе будет проще обсудить более выгодный трек роста

2️⃣Задаешь слишком много вопросов — провалил собес

Во время собеса ты главный. Интервьюер выступает в роли бизнес-заказчика. Тебе нужно узнавать доп инфу и вести диалог. Но решение предлагаешь ты. Вопросы должны быть только по условиям, а не по твоим действиям.
Давай представим 2 ситуации:

Ситуация 1
- А подскажи, ок ли, если для MVP мы забьем на отказоустойчивость не ключевых доменов?
- Да
- Супер, тогда давай сейчас обратим наш взор на доработку главного модуля

Ситуация 2:
- Окей ли сейчас забить на эту часть, чтобы спроектировать более важное?
- Да
- Хорошо. А окей ли нам использовать вот такой паттерн?

В общем, ты должен получать какой-то кусок информации, и дальше им пользоваться.

3️⃣Выбор без пояснения — провал. Лишняя болтовня — тоже провал((

Когда делаешь выбор в сторону готовой технологии, важно кратко сказать, почему именно она, какие там принципы работы. Условно, ClickHouse, потому что нам нужна column-oriented БД и нас устраивает задержка от записи до прорастания во все реплики.

Но в то же время, если при выборе технологий, например, того же load balancer, ты начинаешь в деталях описывать все уровни OSI, или при выборе БД рассказываешь про все виды баз данных — это лишнее, и только создает суету на собесе.

Теории должны быть в меру, только чтобы обосновать твой выбор

4️⃣Знаешь, как тебя оценивают — ты на шаг впереди.

Держи примерный формат, по какому принципу тебя могут оценивать на секции. Обрати внимание на пункты и подпункты.


Теперь ты вооружен и готов к своему собесу по system design в ❤️


А что там у фронтов? У них тоже есть секция со своими приколами. Достаточно много нюансов уделяется технологиям (да, на фронте немного отличается от бека), безопасности — но это уже на отдельный пост, ставь сердечко, и я разберу дальше♥️

Сборник ресурсов по system design

Вчера меня попросили скинуть старые записи лекций/практик по system design. Решил собрать в небольшую подборку, чтобы ты смог освежить знания, а также узнать новое:

🟡Лекция про теор основу для system design: раз, два

🟡Лекция про особенности собесов в Т-Банк: жмак

🟡Практика: проектируем Авито, другая версия

🟡Бесплатный курс на Stepik от меня. Пройдемся по всей базе, спроектируем мессенджер, поговорим об особенностях собеса

🟡Эфир от июля, где рассказываю про вилки в компаниях, основные блоки в проектировании для любой системы, а также раскрываю несколько паттернов

Также глянь посты в этом канале:
🟡Про секцию system design в Яндекс
🟡Про паттерны надежности

Крутой подготовки тебе!⚡️

Как решить популярную задачу на секции system design в красный поисковик?

Именно такую задачу мы решали в рамках мок интервью внутри сообщества

В чем суть задачи:

Требуется спроектировать сервис Пробки.
Сервис должен уметь рисовать на карте пробки (десктоп, мобильное приложение).
Пользователи сервиса – все автомобилисты мира.
Источник данных – треки пользователей.

Вот такая нехилая задачка.
Ну, давай проектировать по шагам 🦶


1️⃣ Классика про ФТ (функциональные требования) и НФТ (нефункциональные требования)

ФТ
🔘Как пользователь видит пробки? Только в рамках своего экрана или все? ▶️Для экономии ресурсов девайса берем только экран
🔘Что есть source of truth по пробкам? ▶️ Данные от самих пользаков

НФТ
🔘Есть ли какие-то ограничения по response time? ▶️ 200 мс
🔘Какое кол-во DAU? ▶️ 200 ms на этапе MVP
🔘Планируется ли рост? ▶️ Да, до всего мира. Условно 1 миллиард
🔘Как часто будем опрашивать девайсы для получения инфы и как часто клиенты будут ходить к нам? ▶️ 6-10 раз в минуту каждый клиент пушит в нас данные и 1 раз в минуту запрашиваем состояние экрана

Далее делаем все расчеты

2️⃣ Доменыыы

Без них никуда:) Тут по сути их 2:

- Получение инфы о пробках и все черная магия
- Другой же связан с отдачей инфы клиентам

Если не знаком с ними, то глянь небольшой пост в канале

3️⃣ Что по сервисам внутри доменов?

Для домена получения инфы нашим сервисом

🔵Сервис преобразования долготы и широты (а именно так определяется локация клиента) + user_id в segment_id. Этот segment_id понабодится далее для более удобной работы с локациями

🔵Сервис скорости 🚤. Он смотрит прошлый сигнал клиента и высчитывает разницу с текущим. Да, можно сразу считать скорость на клиенте, но здесь пошли в более хитрую вариацию.

🔵Сервис аналитики пробок. Данный сервис получает инфу из сервиса скорости и маппит участок дороги (трасса, маленькая улица) с скоростью. Делает он это не по каждому клиенту, а по выборке в n клиентов, чтобы быть объективным. Если скорость маленькая на обычной дороге, то значит пробка.

Например, для обычной дороги:
20 km/h - 🔴, пробка
40 km/h - 🟡, небольшой затор
60 km/h - 🟢, свободно

Для домена отдачи инфы

🔵Сервис преобразования долготы и широты. При запросе ему нужно смаппить много данных по долготе и широте (так как нужно показать пробки на весь экран) в массив сегментов.

🔵Сервис состояние сегментов. Сервис аналитики выше сделал расчеты, но для отказоустойчивости хранить данные мы будем в отдельном сервисе. Именно этот сервис получает массив сегментов и отдает состояние дороги на экране

4️⃣Что еще?

🔘В начале нужно обсудить флоу от клиента до системы (geoDNS, Api Gw, Load Balancers)
🔘Между сервисами следует продумать правильные интеграции (синхронные, асинхронные: http, событийка)
🔘Мониторинги и как мы будем понимать, что где-то проблема
🔘Краевые случаи: что если мало сигналов по какому-то участку, как находить фрод


В общем, система очень сложная, но интересная🔥 Теперь можешь не очковать, что душнила из Big Tech завалит тебя.

Кайфового дня!

Как правильно делать крупные задачи, чтобы не вылететь из компании

Вот тебе дали сделать фичу. И ты понимаешь: «Так-так, тут выглядит посложнее, чем навернуть CRUD». А ты точно уверен, что сложнее и кто-то уже такое не сделал? Не всегда нужно проектировать сервис с нуля и проходить через мясо.

В Big Tech уже придумали, как решать подобные задачи. От компании к компании этот способ может разниться — RFC, Design Doc и прочие непонятные названия.

Но базовые принципы одинаковые, и сейчас я расскажу тебе, как подходить к каждой задаче как папа.


Шаг 0. Зачем вообще нужно что-то прорабатывать перед разработкой?

🟣Чтобы не делать, лишнего, вдруг такой функционал уже есть
🟣Чтобы сразу продумывать на будущее, как дальше будет развиваться продукт, а то, к примеру, при масштабировании придется всё переделывать
🟣Чтобы можно было понятно объяснить другим, что и зачем ты сейчас делаешь
🟣Ну и как минимум — чтобы ты реально сделал что-то толковое, а не то, что первым пришло в голову.


Шаг 1. Собираем требования

🆕 Внимание! Этот опыт будет очень важен на поведенческой секции. Он показывает, умеешь ли ты конструктивно общаться по задаче, получать нужную информацию и договариваться с людьми.

Представь, тебе дали бизнесовое/продуктовое описание проблемы. Что делать дальше?

🟣Провести грумминг проекта с заказчиком (менеджером, team lead или другими представителями вне команды).
🟣Определить один или несколько milestone — то есть выделить этапы разработки продукта, чтобы пользователи могли на каждом что-то нужное для себя получить
🟣Обсудить сроки и последовательность раскатки.
🟣Понять, какая будет нагрузка.

На собесе могут спросить «Расскажи про сложное взаимодействие со смежниками?». И если у тебя есть кейсы, как ты выстроил коммуникацию по продукту, на фоне других ты уже «взрослый» кандидат — а не просто чел, который хорошо делает только по указке, но сам обсуждать задачу не умеет.


Шаг 2. Изучаем всё вокруг нас

Зачем?

🟣Чтобы узнать, существуют ли решения, которые можно использовать в этом проекте
🟣И убедиться, что они подходят под конкретные требования.

Реальный пример: тебе нужно понять, ездила ли машина за последние две недели в тарифе Ultima. Но API умеет лишь отдавать разделение на тарифы «Такси»/«Доставка»/«Межгород». Данный пример более рафинированный, но представь: ты прорабатывал несколько недель, начал писать код, и выясняется, что одна непроработка стопорит весь проект.


Шаг 3. Рисуем архитектуру

Используем C4 (если не шаришь, что это, то ставь 🤔 и напишу мини-гайд).

Накидываем наши существующие сервисы, новые сервисы и сервисы других команд — так мы увидим все необходимые интеграции. Теперь детально прорисовываем эти интеграции и оптимизируем flow.

Что здесь важно проверить:

🟣Проанализировать возможные «костыли» в решении
🟣Подумать, является ли решение системным и масштабируемым
🟣Убедиться, что ты выбрал правильные технологии и сервисы
🟣Посмотреть, можно ли убрать некоторые компоненты или действия
🟣Оценить, выдержит ли твоя архитектура требуемую нагрузку


Финалочка

❗️Важно: каждый этап нам нужно фиксировать в документе. Ведь дальше все эти словеса и архитектура поедет на ревью:
🟣В твою команду
🟣Смежную, если затрагиваешь их сервисы
🟣Арх коммитет, если такой есть в команде

А еще этот док будет служить артефактом на performance review. Если не шаришь про это, то вот пост.

Ну, теперь ты знаешь, как подходить к задачам, чтобы не переделывать их в ночи и не бояться за кривую систему.

Как оценивают frontend разрабов в красном поисковике

В посте пару недель назад говорили про оценку для backend инженеров. Очень многих заинтересовало: А как же оценивают фронтендеров?

Ниже собрал примерный список, по которому оценивали знакомого фронтендера.

Оценка кандидата проходит по шести ключевым направлениям. В каждом — собственные критерии с баллами 0-2 и важные антипаттерны, на которые стоит обращать внимание.

1. Архитектура системы (0–2 балла)
Оцениваем, насколько кандидат понимает структуру приложения и учитывает её качество.

1️⃣ балл: описывает базовую архитектуру (фронтенд + бэкенд + база данных + балансировка нагрузки), обозначает основные компоненты системы.

2️⃣балла: запрашивает и учитывает требования к нагрузке и надёжности, предлагает чёткую и логичную схему, продумывает балансировку, авторизацию, микросервисы (только при обоснованной необходимости), отказоустойчивость.

✖️Антипаттерны✖️
– необоснованное дробление на микросервисы;
– неясное понимание базовой схемы (балансировщик → фронтенд → бэкенд);
– хаотичная, непонятная архитектура.

2. Слой хранения данных (0–2 балла)
Как кандидат подходит к моделированию и выбору хранилища?

1️⃣ балл: описывает модели данных (JSON, сущности, связи); выбирает SQL или NoSQL хранилище.

2️⃣ балла: аргументирует выбор типа хранилища; учитывает отказоустойчивость; понимает преимущества выбранной базы (транзакции, консистентность, миграции, кэширование, S3, очереди).

✖️Антипаттерны✖️
Неспособность описать модели без привязки к конкретной базе.

3. API и бэкенд (0–2 балла)
Оценивается понимание API: структура, обработка ошибок, технологии.

1️⃣ балл: понятная схема API-эндпоинтов; обработка ошибок; знания используемых протоколов; выбран стек.

2️⃣ балла: глубокое понимание организации API и версионирования; обоснование технологий и опыт работы; учёт ретраев, идемпотентности, ограничения запросов.

✖️Антипаттерны✖️
– хаотичный набор эндпоинтов;
– путаница в маршрутизации;
– неуверенный выбор технологий;
– непонимание протоколов.

Прочитай пост про API, если давно не освежал особенности работы и проектирования данного подхода

4. Интерфейс (0–2 балла)
Отражение понимания фронтенд-разработки и UX.

1️⃣ балл: продуман интерфейс (схема роутов и экранов, крупные блоки); выбран и обоснован стек; опыт работы с системами сборки (Webpack и др.); понимание state management, SPA, SSR; определён поставщик и хостинг статики.

2️⃣ балла: метрики качества (ошибки, скорость); продуктовые метрики; упоминание A/B-тестирования и фичефлагов.

5. DevOps (0–2 балла)
Проверяем, насколько кандидат понимает жизненный цикл и инфраструктуру приложения.

1️⃣ балл: знаком с Linux, Docker, Nginx, SSL; понимает процесс от коммита до деплоя; знает схемы релизов, окружения; упоминает логи, мониторинг, алерты.

2️⃣ балла: работает с Kubernetes и инфраструктурой как код; понимает SLA; учитывает балансировку, CDN, масштабирование; владеет продвинутыми инструментами мониторинга и трейсинга.

✖️Антипаттерны✖️
– отсутствие Linux опыта;
– непонимание деплоя и эксплуатации;
– слабые знания диагностики проблем.

6. Безопасность (0–2 балла)
Оцениваем базовое и продвинутое понимание фронтенд-безопасности.

1️⃣ балл: понимает XSS, экранирование, SQL-инъекции; знает модели безопасности браузера (CORS, CSRF); основы SSL.

2️⃣ балла: разбирается в аутентификации (куки, JWT); сессиях, хэшах, соли; глубокое понимание CORS, CSRF, CSP, защиты от DDoS; бонус — знания по безопасности Linux и инфраструктуры (osquery и др.).

✖️Антипаттерны✖️
Знание теории без практического применения, игнорирование безопасности в разработке.


Этот чек-лист поможет тебе объективно оценить свои знания и опыт как frontend инженера. А также выявить пробелы и антипаттерны, которые могут стать угрозой для качества продукта.

Ставь сердечко, если пригодилось♥️

Есть ли рост для инженера, если я вертел все эти встречи и работу с людьми🙃

Карьерный пост в субботнюю ленту📰

Как многие уже знают (а если нет, то узнаешь), существует условная градация intern 🔜 junior 🔜 middle 🔜 senior 🔜 senior+

В этом посте остановимся на части senior и выше. Вот ты уже крутой программист, перфомишь задачи как Рэмбо. Казалось бы, а как расти дальше?🧐

Обычно развитие дальше подразумевает концентрацию на определенных навыках и прокачку в них.

Ниже я приведу архетипы, которые часто используются в западном Big Tech:

• Architect - Builds solid foundations for complex, critical problems. Thinks a few steps ahead.
• Coding Machine - Hyper-productive individual contributor.
• Fixer - Discovers and diagnoses impactful problems and fearlessly jumps in to fix them.
• Generalist - Versatile career learner who quickly ramps up in new areas.
• Product Hybrid - Can guide a team to product/market fit and make early decisions about what to build and why.
• Specialist/Domain Expert - Deeply knowledgeable in a particularly valuable area such as Security, Machine Learning, or Payments.
• Tech Lead - Exhibits managerial and leadership skills in getting the best out of other engineers.


Но тут ты скажешь: а можно ли везде прокачать эти навыки? И мой ответ - нет. Давай разберем пару примеров:

1. Ты работаешь в продуктовом отделе. Это означает, что чаще всего тебе нужно быть Architect, Coding Machine, Product Hybrid. Тебе нужно продумывать архитектуру, писать много кода и помогать выводить продукт на рынок.

2. Или же ты работаешь в команде инфраструктуры. Скорее всего, тут ты будешь Architect, Specialist/Domain Expert. Почему так: ты должен также уметь разбираться в архитектуре, но помимо этого быть экспертом в какой-то области (БД, мониторинг и тд)

3. А сейчас ты работаешь в команде, которая отвечает за надежность сервисов (разработчик/SRE). Это означает, что ты Fixer, который умеет понимать проблемы систем и решать их.

То есть ты выбираешь свой трек и начинаешь целенаправленно развиваться именно в нем.


Как видишь, рост разработчика не заканчивается на уровне senior. Например, в том же ❤️ существуют грейды senior+ и выше, которые вполне реально получить. Однако ключевой момент: не каждая команда или отдел сможет предоставить возможности для роста по любому из этих треков. Поэтому выбирай направление осознанно и обязательно обсуждай свои карьерные цели с руководителем! ✔️

#career #senior

Почему важно проектировать разные системы, а не делать одно и то же

Ты знаешь, что при проектировании есть разные системы: лента📱, мессенджер 📨, сокращатели ссылок🔗 и прочее

А что если я тебе скажу: нужно хотя бы 1 раз в месяц разбирать архитектуру новой системы

Звучит смело, но давай по пунктам

1️⃣ Это развивает тебя как инженера

Все мы работаем в какой-то доменной области. Даже не так, все мы работаем в какой-то подобласти этой большой области.

Если ты работаешь в банке, ты не делаешь всю систему с полного 0, а отвечаешь например, за скоринг клиента при подаче на кредит. Или ты работаешь в соц сети и отвечаешь за аналитику по клиенту.

То есть ты не сталкиваешься в одном месте с write-heavy + read-heavy + devops + OLAP + OLTP + low-latency и проч умными словечками.

Можно, конечно, каждые 6 месяцев менять работу, но:

🟡Ты сам за это время только-только погрузишься в контекст и начнешь брать более сложные задачи

🟡Будут вопросики к твоему опыту


В общем, остается либо брать много разных проектов внутри компании (но на постоянке это путь к выгоранию), либо искать доп возможности — конфы, свои проекты и вот такое «факультативное» проектирование систем.

2️⃣ Это готовит тебя к собесу

Ты будешь всегда готов к потенциальному собесу по проектированию на senior и грейды выше, так как в фоне изучаешь новые подходы и концепции, которые не всегда можно встретить на своей работе.

Причем это не "тупая молотилка", когда ты что-то заучиваешь для собеса. Это, скорее, твоя общая подготовка как спеца, которая будет заметна и на собеседовании.

3️⃣ Это расширяет твое сознание как программиста

Ты понимаешь, какие решения есть в мире (допустим, как Uber работает с гео-данными или Биржа достигает low-latency). И это толкает тебя искать более сложные задачи, а не сидеть на своем комфортном месте.

И, конечно же, ты можешь претендовать на гораздо более высокую вилку. Условно, если ты по шагам умеешь вдумчиво проектировать задачу как в этом посте, то 500-700к для тебя обычная зп.


🏴‍☠️ Финалим 🏴‍☠️

Короче, архитектура это супер крутой способ прокачаться и понять, как отдельные технологии работают вместе, чтобы решать бизнес-задачи.

AI-списывальщики наступают! 🤖

Отвлечемся от сурового system design и поговорим о собеседованиях. А если более конкертно - об использовании AI.

В который раз на собеседовании встречается кандидат, который явно списывает решение с помощью AI.

И проблема не в том, что кто-то пользуется AI, вместо того чтобы с закрытыми глазами писать код на бумажке. Я совсем не против AI в работе и даже на собеседованиях.

Проблема в другом: я прошу кандидата проверить свое решение, которое очевидно нерабочее, а он говорит: «Выглядит окей». Затем начинаю спрашивать про ту или иную строку кода, и кандидат не может толком ничего объяснить.

Коронная фраза одного из кандидатов, после того как я прямо сказал, что в коде ошибка, и показал, как её исправить: «Ну, в общем-то, справедливо»👐

Ниже прикреплю ряд паттернов (да, паттерны у нас не только в архитектуре🙃), которые чаще всего выдают таких ребят.


🐣Уровень Easy

1. Бегающий взгляд. Причем не обычный читающий, а прямо дерганный (как будто пытается сравнить свое решение в AI с тем, что перенес в редактор).

2. Зачем-то копирует весь код/условие в редакторе (скорее всего, чтобы перенести в AI-модель).

👻 Уровень middle

1. Несколько раз переспрашивает тебя про одно и то же.

2. Выдает нерабочий код, который явно плохой и не будет работать. Ты спрашиваешь, все ли окей — он уверенно кивает.

3. Сразу пишет решение от и до. Практически не останавливается на подумать и не рассказывает, почему здесь сделал так, а не иначе.

😮‍💨 Здесь можно перестать наблюдать за кандидатом, а взять эту задачу и самому закинуть ее в AI (можешь потестировать разные модели).

Часто можно увидеть, что он даже не пытается изменить структуры или naming.

🥷🏿Уровень hard

1. Начинаем спрашивать, почему здесь поставил if или почему здесь обрабатывает exception таким, а не другим способом — и кандидат начинает плыть.

2. Пишет код, что-то бормочет, но ты не видишь в этом никакой последовательности.

Это скорее обрывочные мысли: тут напишем цикл, тут у нас if/else, а тут вот такую ошибку захэндлим. Все это происходит без четких связок: «Я сделаю такой цикл, потому что... А здесь я обработаю такие и такие ошибки потому что…»

3. Начинаем копать вглубь: «Вот если по алгоритму делаем отправку offset, а потом отправляем сообщение в очередь, то у нас потенциально после отправки offset может произойти ошибка. То есть мы зафиксируем кусок, но еще раз эти данные не получим. Если без транзакций, то как можно решить?» → Проверяем знание идемпотентности


🤖 В общем, да, хоть с AI сейчас работают все и это крутой инструмент, не забывай использовать свой естественный интеллект. AI не всегда дает правильные ответы, и галлюцинации никто не отменял, так что слепо следовать ему точно не нужно

ТОП книг и статей для роста по скиллам и ЗП

Не так давно на работе проводили клуб по кабанчику🐗. Достаточно популярное явление: собираются ребята и обсуждают прочитанную главу Designing Data Intensive Applications. Часто книжные клубы стартуют именно с этой книги📕

И тут подумал: так много книг и ресурсов, но все их читать - 🤯

Поэтому подборочка, которая в свое время помогла мне за 2 года развиться от 100к до 350к 🤑


Старутем👌

Кабанчик (DDIA) - 1️⃣ книга, которую рекомендую прочитать. Помню, когда начинал читать, то первые главы не зашли. Вообще думал, нафиг эту книгу. Но потом чем дальше, тем интереснее.

Допустим, подробно разбираются индексы и в чем отличие clustered от covering index, модели консистентности. В общем все необходимое для проектирования распределенных систем 🌍

Кстати, скоро выйдет обновленное издание! 🆕

Под номером 2️⃣ у нас Building microservices by Sam Newman. Если только начинаешь проектировать, то это прям пушка. Автор разбирает от типов интеграций до масштабирования решений.

Детально рассказывается про CI/CD и ошибки с ним, а также как по компании понять, какая у нее архитектура

Под 3️⃣ у нас поезда 🚅

Java concurrency in practice - библия для опытного Java разработчика. И в целом полезная книга по многопоточке.

Работа с shred объектами, liveness, nonblocking алгоритмы - короче покупай физическую книгу и клади на стол.


Дальше у нас подборка papers🗞

"Часто прочтение хорошего paper по технологии помогает разобраться в теме лучше, чем книга" - мой знакомый Tech Lead из YouTube

*️⃣Apache Cassandra paper - прочитай и будешь понимать, как устроены кольцевые БД. Всего 6 страниц!
*️⃣Google Cloud Spanner - как обеспечить strong consistency по всему миру. 14 страниц и ты начнешь лучше разбираться в одной из самых сложных тем в программировании
*️⃣Apache Kafka paper - no comments. Самый популярный брокер. Современный Booking по факту построен на этой технологии. Redpanda, logbroker (самописная C++ аналогия из ❣️) - многие работают по похожей механике
*️⃣YT - современный open-source Map-Reduce от Яндекс

Забирай себе, чтобы не кидаться от книги к книге и не терять свое время ⏳

Ставь ✍️, если заинтересовал хотя бы 1 ресурс отсюда

Kafka устарела😳

Тут LinkedIn выкатили новый подход к Kafka.

Kafka стала де-факто стандартом для работы с большими данными.
Но LinkedIn рассказали про свою новую обвязку — Northguard и Xinfra. Давай разберем, что там за магия.

Короче, в чем соль? Почему им стало тесно в обычной Kafka?

У LinkedIn масштаб, который многим и не снился: сотни Kafka-кластеров, тысячи брокеров. И у них были классические «боли роста»:
🔵Клиенты были намертво привязаны к брокерам. Хочешь перенести топик на другой кластер для балансировки? Сорян, иди договаривайся с сотней команд, чтобы они поменяли у себя конфиги и перезапустились
🔵Операционный ад с репликацией. Стандартный инструмент для этого — MirrorMaker — превратился в их главного врага

Что такое MirrorMaker? Для тех, кто не в курсе: это стандартная утилита от Apache Kafka для репликации данных между разными Kafka-кластерами. Нужна для геораспределения или создания бэкап-кластера в другом дата-центре.

Проблема в том, что MirrorMaker — stateful (хранит в себе состояние оффсетов), сложен в управлении и жрал у них CPU как не в себя.

Что они придумали?

Они не стали пилить «убийцу Kafka». Вместо этого они построили над всем своим зоопарком кластеров абстракцию, очень похожую по философии на Control Plane в Kubernetes.

Представь: Kafka-кластеры — это твои worker-ноды, а новая система — это Kubernetes API Server + контроллеры, которые всем этим управляют.

1️⃣ Northguard — это и есть их Control Plane

Это «мозг» всей системы.

🔵Как работает: Разработчик больше не думает о физических кластерах. Он работает с логическим топиком. Например, profile-updates-logical
🔵Клиентское приложение при старте идет не в Kafka, а стучится по gRPC в Northguard Controller
🔵Контроллер лезет в свою базу метаданных (что-то типа их внутреннего ZooKeeper) и говорит клиенту: «Окей, твой логический топик profile-updates-logical сейчас физически лежит на кластере kafka-cluster-053 вот по этим адресам. Иди туда»
🔵Вся магия в миграции: Когда админам нужно перевезти топик (например, со старого железа на новое), они просто меняют эту запись в Northguard Controller. Клиенты автоматически подхватывают новый адрес и бесшовно, без даунтайма переключаются на новый кластер

2️⃣ Xinfra — движок репликации на стероидах

Это их замена для MirrorMaker

🔵Главная фишка — он stateless. Он не хранит оффсеты у себя. Как? Он просто использует стандартный механизм consumer groups в целевом кластере, чтобы коммитить туда прочитанные оффсеты. Упал инстанс Xinfra? Не беда, поднимаем новый, он читает последний коммит из Кафки и продолжает с того же места. Гениально и просто.
🔵За счет этого он легко горизонтально масштабируется: нужно больше пропускной способности — просто запускаешь больше его копий.
🔵Бонусом он умеет делать трансформацию сообщений и репартиционирование на лету во время репликации

Плюсы и минусы

➕
🔵Просто космос для эксплуатации: Миграция топиков без простоя и без дергания сотен команд.
🔵Экономия: Выкинули 1000+ хостов со старым MirrorMaker, высвободив кучу CPU.
🔵Надежность: Убрали единую точку отказа в репликации.

Аналогия с K8s не случайна: Control Plane (Northguard), который отвечает за управление, полностью отделен от Data Plane — слоя, где живут и перемещаются сами данные. В этот Data Plane входят и сами Kafka-кластеры (как хранилище), и Xinfra (как движок репликации между ними). В будущем под этот Control Plane можно будет подсунуть любую другую систему очередей, а клиенты этого не заметят.

〰️
В статье, конечно, сплошная история успеха. О минусах и подводных камнях внедрения такой махины они тактично молчат. Но очевидно, что разработка и внедрение такого слоя — это адски сложная задача.


Результат

Система уже в проде и ворочает триллионами сообщений в день. А теперь самое интересное:

LinkedIn заявили, что находятся на пути к тому, чтобы ЗАОПЕНСОРСИТЬ Northguard и Xinfra!🔥

Так что скоро, возможно, мы все сможем пощупать этот «Kubernetes для Kafka» своими руками

Лучшие посты для твоего развития

В последнее время появилось много новых подписчиков, поэтому решил посвятить пост самым интересным темам в канале😋


Чек-листы/алгоритмы

1. Список лучших книг и статей по архитектуре

2. Сборник бесплатных ресурсов по system design

3. Алгоритм прохождения секции system design

4. Алгоритм по использованию C4


Собесы

1. Проблема с AI на собесах

2. Пример секции behavioral interview (поведенческое интервью) с Booking software engineer

3. Как проходит секция system design в Яндекс для backend разработчиков

4. Как проходит секция system design в Яндекс для frontend разработчиков


Архитектура

1. Что заменит Kafka в скором будущем

2. Топ ошибок при проектировании API

3. Что такое NTP и почему это крит для распределенных систем

4. Несколько паттернов для надежности твоей системы

5. Как спроектировать сервис пробки

6. Как делать крупные задачи в Big Tech

7. Как я чуть не уволился из Т-Банк


Карьера

1. Как не получить плохую оценку на performance review

2. Куда расти после senior

Почему Netflix может стримить 200М пользователей одновременно, а твоя очередная фича задыхается? 🎬 Знакомьтесь, Cassandra


В канале время от времени рассказываю о способах спроектировать систему или каких-то фишках. Но понял, что не хватает ОТ И ДО😎

Вот взять какую-то рабочую систему и препарировать разные концепции. Причем что-то СУПЕР крутое. Что работает во многих Big Tech (Netflix, Apple, Spotify etc) и доказало валидность примененных архитектурных принципов🤨


Apache Cassandra...🙋


Представь, что твоя фича сначала запустилась на маленький город, а потом сразу на всю РФ и весь мир. Пользователи растут быстрее, чем time complexity у двойного цикла😧

До поры до времени можно сделать вертикальное масштабирование. Далее в бой идет горизонтальное. Но тут мы упираемся в сложности масштабирования SQL БД и ограничения движка (B+ Tree)

А теперь представь Netflix. У них сотни миллионов пользователей, которые каждую секунду генерируют данные: что смотрели, где остановились, какие оценки поставили. Ни один, даже самый мощный, сервер в мире этого не выдержит🦉

Именно для таких задач и была создана Cassandra. Вот её суперсилы:

💡 Почти бесконечное горизонтальное масштабирование. Кластеру не хватает мощности? Не нужно покупать сервер-монстр. Просто добавляешь еще одну обычную машину. И еще одну. И еще💪 Cassandra сама распределит данные и нагрузку.

💡 Высочайшая доступность. Cassandra спроектирована так, чтобы не падать. Вообще. В ней нет "главного" узла (master), который мог бы стать единой точкой отказа. Любой сервер может отказать, но кластер продолжит работать как ни в чем не бывало. Для пользователей это выглядит как магия. Для нас, инженеров, — как грамотный дизайн.

💡 Молниеносная запись. Архитектура Cassandra (о ней поговорим отдельно) оптимизирована для экстремально быстрой записи. Данные пишутся последовательно, что является одной из самых быстрых дисковых операций. Её архитектура записи обходит ограничения, с которыми сталкиваются классические B+-деревья в SQL-базах при огромном потоке данных


Конечно, за всё приходится платить. Цена — это другой подход к моделированию данных и так называемая "итоговая согласованность" (eventual consistency).

В ряде следующих постов:
🟣Заглянем под капот и разберемся, как она хранит данные (LSM-деревья)
🟣Поговорим о "сплетнях" между узлами (Gossip-протокол)
🟣Постигнем магию настраиваемой согласованности (QUORUM)
🟣Узнаем, как кластер сам себя лечит (Hinted Handoff, Read Repair)
🟣И, конечно, разберем главные ошибки, которые могут убить твой перформанс

И много чего еще, что поможет тебе на собесе и в работе. Ведь основные концепции используются и в других распределенных системах🖥


😎 - если зашло и ждешь next post