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

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

Как многие уже знают (а если нет, то узнаешь), существует условная градация 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 — механизм записи

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

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

Как стать team lead/senior к 25 годам?

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

Так и появился эфир. А самое ценное с эфира расскажу ниже по пунктам

Ты: "Даня, как мне максимально эффективно развиваться, чтобы к X годам стать лидом или сеньором?"


1️⃣ Делаем разнообразные задачи

Иначе говоря: зона комфорта тебя убьет.

Вот скажи мне, ты 100% видел чуваков, которые вроде бы долго работают уже, но все сидят на своем грейде (и чаще всего это не какой-нибудь senior+ с супер крутыми скиллами и ЗП 600к+)

Поэтому уже в зеленые джунские годы нужно просить разные задачи:
🔵На этой недельке делаем API
🔵На след настраиваем стенды для dev/prod и копаемся с helm
🔵Затем проводим нагрузочное тестирование и устраняем недостатки нашего сервиса

Кстати, пункты выше это прям реальные примеры, чем я занимался как junior специалист

Сложно было п**дец, но зато скилуха росла, как на дрожжах

И да, время будет уходить больше, но если ты настроен на быстрый рост (особенно это актуально для junior/middle позиций), то такова цена


2️⃣ Не учимся просто так

Вернее так: не нужно учится всему, так как инфы в IT ну слишком много

Бери разные задачи и в рамках них читай статьи/книги, смотри видео или даже можешь глянуть какой-то курсец.

Но прошу тебя, без типичной ошибки (которая кста была и у меня): "Ща пройду курс на 100 часов по фреймворку и потом начну его использовать"

Как говорил один сеньор: открыл quickstart и погнали

Допом можно проходить курсы, чтобы углубиться в какие-то темы (например, больше узнать про system design или быстро качнуться в каком-то ЯП)


3️⃣ Не сидим ровно, а заявляем о росте

Формула такая: въ*быч + заявление о росте

Если в компании есть performance review, то на них должны быть подвижки. Если получаешь ответы из серии: "ну посмотрим", "давай подождем", то это красный флаг 🚩, что о долгосрочном росте сотрудников не парятся. Тут либо ротироваться, либо искать другую компанию


4️⃣ Учиться в коммуникацию

Это одно из моих любимых

Почему-то ребята в ИТ считают, что коммуникация это не для них. Но вот что я тебе скажу:

Без умения в коммуникацию ты будешь дольше расти. А на ряде позиций вообще не сможешь выполнять задачи

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

Как я качал коммуникацию в свое время:
🔵Проводил внутренние митапы на команду/отдел. Изучил что-то новое, сделал интересную фичу - рассказал. В начале будет сложно, но потом начнешь ловить кайф от умения кристально четко доносить информацию
🔵Сходить на курсы ораторского мастерства

Также используй паттерн: проблема - решение

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


5️⃣ Если хочется в лида, то есть 2 путя

№1: заявить о желании своему руководителю или skip-level (руководитель +1). И если текущий руководитель уйдет или будет расширение - ты кандидат на эту позицию

№2: зайти в компанию на разработчика с треком роста в лида (обсуждается на финальных секциях)

Я шел по второму этапу

Совет: ищи команды, которые развиваются. Так как у ребят "на поддержке функционала" маловероятно, что будут такие возможности

6️⃣ С точки зрения лида опыт прям супер важен

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

Безусловно, есть много полезных книг/курсов, но сугубо мое мнение: все упирается в умение решать кейсы:
🔵Найм
🔵Увольнение
🔵Нехватка ресурсов (время, люди)
🔵Факапы

И у каждого из пунктов может быть большое кол-во комбинаций. Так что самое крутое это ворваться и на собственной шкуре все понять + получать ОС от опытного руководителя в компании


7️⃣ Заграницей также можно кайфово жить

Не хватает букв в посте ТГ...


Если пост наберет 50 ♥️, то напишу вторую часть

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

gRPC медленнее REST? Кейс из прода

Лови недавний прикол из прода. Внедрили gRPC, ждали космос по перфомансу, а тайминги... выросли по сравнению с обычным REST 🤦‍♂️

Начали копать. Оказалось, мы забыли включить сжатие. В gRPC оно по дефолту ВЫКЛЮЧЕНО

И это не баг либы, а фича и осознанное проектное решение gRPC

Все дело в трейд-оффе: CPU 💻 vs Сеть 🌐. Но на решение, сжимать или нет, влияют два главных фактора:

1️⃣ Скорость сети
Внутри одного дата-центра на 40 Gbit/s и в мобильной сети 3G — это две разные вселенные. Для медленных сетей (интернет, мобилки) сжатие — почти всегда must-have, потому что сеть — главное узкое место.

2️⃣ Объем данных (payload)
А вот это — ключевой момент, который мы тоже упустили!
🟣Если ты гоняешь мелкие, частые запросы типа ping или getUser_by_id, выигрыш от сжатия может быть съеден затратами CPU.
🟣Но если ты передаешь большой объем данных (список на 1000 объектов, файл, JSON на мегабайт), то сжатие даст огромный буст ДАЖЕ на сверхбыстрой сети. Выигрыш во времени от уменьшения payload (с 10 МБ до 1 МБ) всегда больше, чем траты CPU на сжатие этих данных


🤔 «Но ведь там Protobuf, он же и так компактнее JSON?»
Да, Protobuf — это эффективный формат. А Gzip — это алгоритм сжатия поверх него. Для маленьких сообщений разница будет невелика. Но на больших объемах Gzip находит и сжимает повторяющиеся последовательности в данных, и экономия будет колоссальной. Это два разных, дополняющих друг друга уровня оптимизации.

TL;DR

🟣Это не баг, а фича для тонкой настройки производительности
🟣Когда включать сжатие (Gzip):
- Связь идет через интернет/WAN/мобильную сеть
- Передаются большие объемы данных (даже в быстрой сети)
🟣Когда можно не включать (и протестировать)?
- Сервисы в одной быстрой сети (ДЦ, Kubernetes) и гоняют друг другу много мелких, частых сообщений

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

Если не сталкивался раньше с таким, то ставь🔥