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, чекни свои настройки. Возможно, там тоже скрыт легкий буст производительности, особенно если работаешь с большими данными😉

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

Как добиться молниеносных записей в БД

Мы с тобой уже разобрались в прошлом посте, что Cassandra — это децентрализованная система без единого master. Мы много говорили о том, что она оптимизирована для молниеносной записи. Сегодня пора разобраться, как именно достигается эта магия.

Почему B-Tree не всегда подходит?

В большинстве реляционных баз данных (PostgreSQL, MySQL) используется структура данных B+-Tree. Она отлично подходит для сбалансированного чтения и записи. Но когда тебе нужно обновить строку, B-Tree-движку часто приходится:

1️⃣ Найти на диске нужный блок данных (random read).
2️⃣ Загрузить его в память.
3️⃣ Изменить данные.
4️⃣ Записать обновленный блок обратно на диск (random write).

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


LSM-дерево

Cassandra говорит: "Давай не будем ничего изменять на диске. Будем просто дописывать новое в конец!". Эта концепция лежит в основе Log-Structured Merge-Tree (LSM-дерева).

Давай посмотрим на путь запроса на запись

1️⃣Шаг 1: Запись в Commit Log (Гарантия надежности)

Как только узел-реплика получает данные для записи, он первым делом дописывает их в специальный файл на диске — Commit Log

🟡По сути, это "черный ящик" самолета. Простой файл, в который последовательно дописываются все входящие операции. Последовательная запись — это самая быстрая операция с диском.

🟡Зачем? Только для одной цели: восстановления данных в случае сбоя. Если узел внезапно перезагрузится, он при старте прочитает Commit Log и восстановит в памяти все данные, которые не успел сохранить на диск в основном хранилище.

2️⃣ Шаг 2: Запись в Memtable

Одновременно с Commit Log, данные записываются в структуру в оперативной памяти — Memtable
🟡Что это? Отсортированная по ключу таблица в RAM. Все новые данные и обновления попадают сюда. Поскольку все происходит в памяти, это невероятно быстро.
🟡Зачем? Чтобы собирать и сортировать данные перед их записью на диск.

3️⃣Шаг 3: Подтверждение клиенту

И вот он, ключевой момент!

Как только данные записаны в Commit Log (на диск) и в Memtable (в память), узел отправляет твоему приложению подтверждение: "ОК, я всё сохранил"

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

Данные уже находятся на диске, но только в виде быстрой, последовательной записи в Commit Log. Этого достаточно, чтобы Cassandra могла гарантировать, что данные не потеряются даже при внезапном отключении питания. Узел знает: "Если я упаду, я проснусь и восстановлю все из этого лога"

Но при этом данные еще не лежат в своей финальной, структурированной форме — в отсортированном файле SSTable.

Сложная и медленная работа по организации данных в SSTable откладывается на потом и выполняется в фоновом режиме.

Аналогия: Представь, что тебе нужно разобрать тонну почты.
🟡Медленный путь (как B-Tree): Взять каждое письмо, найти нужную папку на полке, положить письмо, вернуться за следующим
🟡Быстрый путь (как Cassandra): Сначала быстро скидать всю почту в один большой ящик (Commit Log + Memtable) и сказать начальнику "Вся почта принята!". А уже потом, когда будет время, спокойно разобрать этот ящик по папкам (SSTable)

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

4️⃣Шаг 4: Сброс на диск в SSTable (The Flush)

Рано или поздно Memtable в памяти заполнится. Когда это происходит, Cassandra:
1️⃣ "Замораживает" текущую Memtable (она перестает принимать новые записи).
2️⃣ Создает новую, пустую Memtable для обработки поступающих запросов.
3️⃣ Асинхронно, в фоновом режиме, сбрасывает данные из замороженной Memtable на диск в виде нового файла.

Этот файл называется SSTable (Sorted String Table)

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

У него два свойства:
🟡Неизменяемый (Immutable): После того как SSTable создан, он больше никогда не изменяется. Никогда. Если тебе нужно обновить или удалить данные, Cassandra просто создаст новый SSTable с более свежей версией или специальной меткой удаления (tombstone).
🟡Отсортированный (Sorted): Данные внутри SSTable отсортированы по ключу, что в будущем ускорит их чтение.

✏️Итог: Путь записи целиком

1️⃣ Запрос на запись -> Узел-реплика.
2️⃣ Commit Log (последовательная запись на диск для надежности).
3️⃣ Memtable (запись в RAM для скорости).
4️⃣ Подтверждение клиенту ("ОК").
5️⃣ (Позже, в фоне) Memtable заполнена -> Сброс на диск в новый, неизменяемый SSTable.

Но подожди... если мы постоянно создаем новые и новые файлы (SSTable) и никогда их не изменяем, то:
1️⃣ Как потом читать данные, если они размазаны по десяткам или сотням файлов?
2️⃣ Что происходит при удалении?
3️⃣ Дисковое пространство не забьется ими до отказа?

На все эти вопросы отвечает фоновый процесс, который называется Compaction. И это — тема нашего следующего поста.

👍 - если все усвоил и теперь понимаешь, как работает LSM

Compaction: механизм в любых соверменных write-heavy БД

В прошлом посте мы оставили Cassandra в интересном положении: она постоянно создает новые, неизменяемые файлы (`SSTable`) на диске. Это обеспечивает молниеносную запись, но порождает три серьезных вопроса, которые ты, возможно, уже себе задал:

1️⃣ Как читать данные?
Если одна и та же строка обновлялась 10 раз, ее версии размазаны по 10 разным SSTable-файлам. Чтобы найти последнюю версию, придется заглянуть во все 10? Звучит медленно

2️⃣ Куда девается мусор?
Старые версии данных и удаленные строки просто лежат на диске и занимают место. Это неэффективно

3️⃣ Как работают удаления?
Если SSTable-файлы неизменяемы, как вообще можно что-то удалить?


Ответ на все эти вопросы один: Compaction

Кстати, данный механизм используется во всех современных БД и Engine DB, нацеленных на распределенность и большую нагрузку: ScyllaDB, RocksDB, Google Bigtable

Что такое Compaction?

Compaction — это фоновый процесс, который занимается слиянием и уплотнением SSTable-файлов. Это внутренняя "уборщица" и "оптимизатор" Cassandra.

Процесс выглядит так:
1️⃣ Cassandra берет несколько SSTable-файлов
2️⃣ Читает их содержимое, строка за строкой
3️⃣ "На лету" сливает данные, следуя простым правилам:
- Данные с одинаковым ключом? Берем только версию с самой свежей временной меткой (timestamp). Все старые версии выбрасываем
- Встретили метку удаления (Tombstone)? Если мы нашли и саму метку, и данные, которые она помечает к удалению, мы можем их безопасно выбросить (при условии, что прошло достаточно времени — gc_grace_seconds — чтобы эта информация разошлась по кластеру)
4️⃣ Записывает результат в один, новый, чистый SSTable
5️⃣ После успешного создания нового файла, старые, "грязные" SSTable удаляются

Аналогия: Представь, у тебя есть 5 версий одного и того же документа Word. Чтобы навести порядок, ты открываешь их все, копируешь самые свежие параграфы из каждого в новый, шестой документ, а старые 5 удаляешь. Compaction делает то же самое, но с данными.


Зачем это нужно? Ключевые цели Compaction:

✅ Улучшение производительности чтения. Вместо того чтобы искать данные в 50-ти маленьких файлах, Cassandra будет искать их в одном большом, что гораздо быстрее
✅ Освобождение дискового пространства. Старые, ненужные версии данных и окончательно удаленные строки физически стираются с диска.
✅ Обеспечение целостности данных в долгосрочной перспективе.


Не все compaction одинаковы:

Compaction — это не просто "взять и слить". Это ресурсоемкая операция (I/O, CPU). Поэтому Cassandra предлагает разные стратегии для разных типов нагрузки. Выбор неправильной стратегии — один из верных способов "убить" производительность кластера.


Краткий обзор трех основных:

🔵SizeTieredCompactionStrategy (STCS): Стратегия по умолчанию. Сливает SSTable примерно одинакового размера. Хорош для write-heavy load
🔵 LeveledCompactionStrategy (LCS): Организует данные по "уровням", где каждый следующий уровень в 10 раз больше предыдущего. Более затратное по I/O, но делает чтение более эффективным
🔵TimeWindowedCompactionStrategy (TWCS): Группирует данные по временным окнам (например, день). Идеально для time-series


Итог 👍

Compaction — это критически важный фоновый процесс, который поддерживает "здоровье" кластера Cassandra. Он борется с фрагментацией данных, освобождает место и делает чтение быстрым. Понимание и правильная настройка стратегии compaction — это ключ к стабильной и производительной работе с Cassandra

Теперь, когда мы знаем, как Cassandra пишет и убирает за собой, пришло время разобраться, как она все это находит. В следующем посте мы пройдем полный путь чтения (релевантный для многих современных БД)

💯 — если стало понятнее, как устроен "движок" Cassandra

Уволен из Яндекса за 1 косяк с БД

И это реальная история, которая произошла на неделе в Яндекс Такси 🚕

Вот тебе нужно сделать изменения в реплику MongoDB. Под репликой имеется в виду не master-slave, а прям отдельное хранилище, в которое уезжают все данные

Внешняя реплика - частое решение в Big Tech. Оно позволяет:
🟡Другим разработчикам изучать структуру данных сервиса
🟡Аналитикам проводить расчеты без ssh в твой сервис
🟡Повышает отказоустойчивость: если с основной БД какие-то проблемы
🟡Заложить ряд процессов на эту реплику. Тут надо быть осторожнее, но иногда для скорости решения идут на такие действия


Одному разработчику нужно было добавить колонку в эту реплику. И по определенной причине стандартные настройки правил репликации в эту реплику (делается через .yaml файлы) не работали

Поэтому он сгонял к maintainers и спросил: "А можно дропну и заново накачу?". Ответ был получен положительный.

А ТЕПЕРЬ ВНИМАНИЕ: по сути он сделал мини-PR, в котором удаляется реплика, а потом опять стартует наливка из MongoDB.

Но за ОК пошел в чат к человеку из своей же команды, а не maintainers. Второй чувак сделал "ок не глядя"


И что по итогу?

Ну, в Южной Америке 70% бизнеса Яндекс Доставки не работали полдня. Был ряд сложностей с Яндекс Такси в Узбекистане. А еще Таксопарки не получали инфу о штрафах машин, не могли смотреть отчеты по тачкам около 2-ух дней

Думаю, что все осознают потенциальные потери бизнеса от этой поломочки... 🪙

Почему все рухнуло: разработчик ожидал, что реплика нальется быстро. Но просчитался в объеме данных и скорости переливки. По итогу вместо посчитанных пары часов все происходило около пары суток.


А еще НЕ fun fact:

В течение суток не было чата по инциденту. То есть никто из коллег, руководителей не знал об этом

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


Что нужно было сделать иначе ✏️

1. Перепроверить свои расчеты по объему данных в БД и реплике. Далее еще раз понять, какая скорость синхронизации данных между этими сущностями

2. Проверить, что нет учений на ближайшие дни. Так как на время учений часто закрывают какой-то ДЦ. И это тоже может выстрелить при синхронизации данных. Почему? Так как в Яндексе есть правило, что ОК по INSERT/UPDATE будет получен только после синка данных на 2-ух ДЦ

3. Нести PR не своей команде, а maintainers

Здесь еще был косяк с ролями. Почему-то не только maintainers могли окнуть его. Но это уже разбирали после

Почему это критично: если бы ОКнули maintainers, то это их головная боль и косяк. А так получается, что косяк создателя PR и ОКающего PR

4. В момент осознания инцидента: создать чат по инциденту

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

6. Придти на разбор инцидентов и проговорить с коллегами, как такое могло произойти и как не допускать такого в будущем

Есть такой термин: blameless culture😳

В инциденте виноват не кто-то 1, а группа людей. Допустим, у нас упал прод. Кто виновать? Разработчик написал такой вот код, но его проревьюил другой разработчик. Затем QA плохо проверил. И еще руководитель, что нанял таких людей

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

Короче, большая и крутая зона ответственности порождает и большие проблемы, если не следовать регламенту и пытаться делать впопыхах 👻

PS: Этого разработчика и "окаря" по итогу не стали увольнять, но оценку "ниже ожиданий" на ревью могут получить как нефиг

Секция с кодом захватила весь РФ Big Tech

Именно под таким слоганом пройдет следующий открытый урок.

TL;DR секция с кодом это «Язык и Платформа», «Кодинг секция» и прочие варианты названий

Уже 3 дня готовлюсь к уроку, так как инфы супер много (особенно вокруг БД и работы с конкурентностью). И это я еще не начинал разбирать примеры задач из красного поисковика🖥

Буду рассказывать про
🟡Особенности секции в разных Big Tech
🟡Какие задачи спрашивают. Причем не просто ответы, а почему именно такое решение. Чтобы прокачать слушателей как инженеров
🟡Как тебя будут оценивать

Если стало интересно и послушал бы потом данный урок, то ставь ❤️