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

Вот тебе дали сделать фичу. И ты понимаешь: «Так-так, тут выглядит посложнее, чем навернуть 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

Когда SQL DB больше не справляется: Наследие Amazon Dynamo

В прошлом посте мы с тобой глянули, что Cassandra — это ответ на проблемы экстремального масштаба. Но чтобы понять её гениальность, нам нужно вернуться в прошлое⌛️

Прародителем Cassandra является Amazon Dynamo

И сразу важнейшая ремарка, чтобы ты не запутался:
🟡Dynamo — внутренняя БД Amazon, которая была представлена аж в 2007 году
🟡DynamoDB — это уже современный коммерческий сервис от AWS, который является реализацией и развитием идей из той самой статьи

Cassandra — open-source реализация, вдохновленная именно принципами из статьи Dynamo

Проблема, которую решал Amazon

Представь себе Черную Пятницу на Amazon. Миллионы покупателей одновременно добавляют товары в корзину. Если база данных корзин "моргнет" хотя бы на пару секунд, компания потеряет миллионы долларов.

Главный вывод, который сделал Amazon: для некоторых задач доступность важнее строгой согласованности. Лучше принять заказ и разобраться с возможным конфликтом потом, чем вообще не смочь его принять.

🧷Это привело к созданию системы, построенной на нескольких революционных принципах.


1️⃣ Принцип Always-On Availability (Приоритет доступности)

Система должна принимать твои запросы на запись и чтение всегда, даже если часть серверов вышла из строя или между дата-центрами пропала связь. Это достигается за счет готовности пожертвовать сиюминутной согласованностью данных. Итого мы получаем eventual consistency

2️⃣ Consistent Hashing и Virtual Nodes

Как тебе распределить данные по 1000 серверов? Наивный подход hash(key) % N (где N — число серверов) ужасен. Как только ты добавляешь или убираешь один сервер, тебе приходится перемещать почти ВСЕ данные 💣

Consistent Hashing решает эту проблему изящно. Представь себе кольцо, на которое помещаются и ID твоих серверов, и хэши ключей данных. Данные сохраняются на ближайшем по часовой стрелке сервере.

Проблема: При таком подходе нагрузка может распределиться неравномерно.
Решение — Virtual Nodes (Vnodes): Вместо того чтобы каждый твой физический сервер был одной точкой на кольце, он представляется множеством "виртуальных" точек.

Что это тебе дает?
🟡Равномерное распределение нагрузки
🟡Гибкое управление кластером при добавлении/удалении узла

3️⃣ Quorum NWR (Настраиваемая согласованность)

Это сердце гибкости Dynamo-подобных систем. Эту концепцию мы с тобой разберем в отдельном посте максимально подробно, с примерами и формулами. Сейчас важно запомнить саму идею:
🟡N — Replication Factor. Сколько копий (реплик) данных ты хранишь.
🟡W — Write Quorum. У скольких из N реплик ты должен дождаться подтверждения записи.
🟡R — Read Quorum. Со скольких из N реплик ты должен прочитать данные.

Если R + W > N, ты получаешь strong consistency (строгую согласованность). А если тебе важна скорость записи, можно выбрать W=1, R=1. Так мы можем управлять балансом между скоростью и согласованностью.

4️⃣ Разрешение конфликтов: Vector Clocks vs. LWW

И вот тут пути Cassandra и Dynamo разошлись😮

Что делать, если из-за проблем с сетью два клиента одновременно изменили один и тот же объект?

🟡Оригинальный Dynamo использовал векторные часы (Vector Clocks). Если конфликт нельзя было разрешить автоматически, обе версии отдавались твоему приложению для ручного разрешения.
🟡Cassandra выбрала более простой путь: Last Write Wins (LWW).

Это правило «побеждает последний» имеет одно огромное последствие, о котором мы тоже поговорим отдельно и очень подробно


🦉Итог

Статья Dynamo — это настоящий манифест распределенных систем. Cassandra взяла эти идеи за основу, адаптировала их и сделала доступными тебе в виде мощного open-source инструмента.


🟡 Оригинальный paper про Amazon Dynamo
🟡 Короткая статья про consistent hashing и vnodes

В следующий раз посмотрим, как именно Cassandra реализует эти принципы в своей masterless-архитектуре и как узлы "сплетничают" друг с другом
🤯 — если мозг немного вскипел, но было интересно
😨 — если плохо разбираешься в моделях консистентности

Архитектура Cassandra: Masterless

В прошлом посте мы с тобой разобрались в принципах из статьи Dynamo. Сегодня посмотрим, как Cassandra превратила эти идеи в реальность.

Готовься, мы погружаемся в самую суть её отказоустойчивости 👨‍🚒

Главный принцип архитектуры Cassandra — Masterless (или Peer-to-Peer). В кластере нет "главного" узла. Все узлы равны. Ты можешь отправить запрос на любой из них, и он будет обработан. Это исключает единую точку отказа и делает систему невероятно живучей.

Держится всё на трёх китах: The Ring, Gossip и Snitch 🐳


1️⃣ The Ring: Как Cassandra понимает, где лежат твои данные

Давай на конкретном примере. Представь, что у нас есть кластер из 4-х узлов: A, B, C, D.


1️⃣ Создание Кольца: Cassandra берет диапазон всех возможных значений хэша (например, от 0 до 2^64-1) и сворачивает его в кольцо

2️⃣ Размещение узлов: Каждому узлу назначается один или несколько токенов (если не читал прошлый пост про VNodes, то глянь). Токен — это просто число из этого диапазона. Допустим, наши узлы получили токены:
🔘Узел A: токен 100
🔘Узел B: токен 400
🔘Узел C: токен 700
🔘Узел D: токен 900

3️⃣ Определение ответственности: Каждый узел становится ответственным за диапазон хэшей от предыдущего токена на кольце до своего собственного
🔘Узел A отвечает за диапазон (901 - 100)
🔘Узел B отвечает за диапазон (101 - 400)
🔘Узел C отвечает за диапазон (401 - 700)
🔘Узел D отвечает за диапазон (701 - 900)

4️⃣ Приходит запрос: Твое приложение хочет сохранить данные пользователя с user_id = 'alex'. Ты отправляешь запрос на любой узел (пусть это будет узел А, он станет координатором)

5️⃣ Вычисление: Координатор берет Partition Key (в нашем случае user_id = 'alex'`), вычисляет от него хэш: `hash('alex') -> допустим, получилось 550

6️⃣ Поиск на кольце: Координатор смотрит на кольцо и определяет, в чей диапазон попадает значение 550. Это диапазон (401-700), за который отвечает узел С.

Вывод: узел C будет хранить первую копию данных (эту копию и называют репликой, replica). Если твой Replication Factor (фактор репликации) равен 3, то Cassandra должна сохранить еще две копии этих же данных. Она разместит их на следующих по часовой стрелке узлах — D и A. Таким образом, узлы C, D, и A являются узлами-репликами для данных пользователя 'alex'.

2️⃣ Gossip Protocol: Как узлы "сплетничают" друг о друге

Окей, но откуда узел A (наш координатор) вообще знает о существовании узлов B, C, D и их токенах? Они "сплетничают" (gossip).

Каждую секунду каждый узел обменивается известной ему информацией о себе и о других узлах с несколькими случайными "соседями". Эта информация (метаданные) распространяется по кластеру как вирус, и уже через несколько секунд все узлы знают обо всех.

Gossip — это децентрализованный и очень надежный механизм обнаружения и мониторинга

3️⃣ Snitch: "Стукач", который делает кластер умнее

Вот ты знаешь, что реплики для 'alex' должны храниться на узлах C, D и A. Но если все они находятся в одной серверной стойке, то при ее отказе ты теряешь данные. Это плохо.

Snitch — это не отдельный сервис и не какой-то "мастер". Это внутренний, настраиваемый модуль внутри каждого узла Cassandra. Его единственная задача — предоставлять информацию о топологии сети. Он как GPS-модуль в твоем телефоне: он не управляет тобой, а просто сообщает твои координаты другим приложениям

Snitch решает эту проблему. И вот как именно работает эта магия:

1️⃣ Шаг 1: Самоопределение. На каждом узле Snitch определяет его физическое местоположение. Например, самый популярный GossipingPropertyFileSnitch читает простой файл cassandra-rackdc.properties, где ты сам прописываешь: dc=dc1 и rack=rack1. Теперь узел знает: "Я в первом дата-центре, в первой стойке".

Продолжение ниже 👇

2️⃣ Шаг 2: Распространение информации. И что дальше? А дальше эта информация о местоположении (`dc1`, `rack1`) добавляется в Gossip-сообщения

Когда узел "сплетничает" с другими, он не просто говорит "я жив", но и "кстати, я нахожусь в dc1, rack1".

3️⃣ Шаг 3: Глобальная карта. Поскольку Gossip-сообщения распространяются по всему кластеру, через несколько секунд каждый узел в кластере имеет полную карту топологии: Узел A: dc1, rack1, Узел B: dc1, rack2, Узел X: dc2, rack5 и так далее.

4️⃣ Шаг 4: Умное размещение реплик. Теперь, когда координатор должен разместить реплики, он использует эту глобальную карту. Он видит, что первая реплика должна быть на узле C (dc1, rack1). Затем, следуя правилам, заданным в Стратегии Репликации (Replication Strategy), он использует эту глобальную карту. Стратегия репликации смотрит на расположение первой реплики (узел C в dc1, rack1) и дает команду разместить остальные копии на узлах в других стойках и дата-центрах


Итог 🏁

🟢The Ring определяет *первичный* узел для данных
🟢Snitch предоставляет информацию о топологии сети
🟢Gossip распространяет всю необходимую информацию на все узлы
🟢Replication Strategy (стратегия репликации) использует эту глобальную карту для умного размещения остальных реплик по разным стойкам и дата-центрам

Все вместе это создает самоорганизующуюся и невероятно живучую систему без единого master


Теперь, когда мы поняли архитектуру "с высоты", пора заглянуть еще глубже. В следующий раз мы разберем, возможно, самую важную часть Cassandra — механизм записи

Если есть какие-то вопросы, то пиши в комментах💬

В остальном жмакай огонек, если вкатило🔥