Как же переписать огромный монолит и стоит ли?

Решил сделать небольшую серию постов про монолиты и МИКРОсервисы.


Вот ты пришел на новую работу и видишь его: монстра с git blame от 2005 года. А для пущего интереса ты еще и на проекте, где нужно переписать это чудо на микросервисы.

Чтож, вводные данные понятны. Давай разбираться

Шаг 0

А нужно ли переписывать вообще? У монолита огромное кол-во плюсов.

Если кто-то говорит, что ТОЛЬКО МИКРОСЕРВИСЫ, А МОНОЛИТ ХЕРНЯ - беги от него. Это кудесник, который натворит бед в проекте😳

Так вот, в чем крут монолит:

🔵Меньшее время отклика. Так как все происходит в одной кодовой базе. Нет лишних network hop (сетевые прыжки), все в рамках одной БД, которая оптимизирована

🔵Гораздо проще делать fallbacks и не нужно городить вереницы из паттернов. Ведь гораздо проще не создавать сначала проблем, чтобы потом их героически разгребать. Simplicity is king

🔵Прогрев монолита: если ты пишешь на каком-нибудь JVM (сори, я в прошлом джавист), то VM'ка сконвертит часть байт-кода в машинный код и будет красота

🔵Не нужно магического CI/CD с десятками артефактов, а потом сложной логики с registry

🔵Внезапно: не нужно раздувать команды X5, так как не будет 100500 сервисов с постоянно дублирующимся функционалом (ставь сердечко, если у тебя в компании есть повторяющийся функционал в разных сервисах). Все под рукой и грамотно организовано

🔵Красота и изящество GoF: эта банда сделала поистинне потрясающие паттерны, которые превращают месево в структуру (тут главное не перегнуть палку, но об этом в другой раз)

🔵При наличии доки и хорошего кода можно быстро разрабатывать и внедрять новые фичи. Ладно, про доку это я загнул и такое очень редко встречал, но если есть знающие коллеги, то все будет ништяк

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


Это была первая часть. В следующей части посмотрим, а когда все-таки стоит делать микросервисы🔜🔜🔜

А зачем нам эти микросервисы?

Продожение серии про монолиты и микросервисы. Если не читал первую часть, то держи: https://t.me/system_design_algocode/34


В общем мы раскидали про все ➕монолитов. Но зачем тогда эти микросервисы нужны вообще?

Прежде чем пилить решение нам нужно 10 раз подумать. А в нашем случае разобраться в чем эти самые сервисы баще


Шаг 0.1

🟢 В большой компании проще разбить продуктовые фичи на зоны ответственности и контролировать процесс. Тут с монолитом будет тяжко. А вот микросервисы прям удобно ложатся в эту парадигму. У каждой команды свои сервисы и в случае падения прода понятно к кому идти👍

🟢 Если какой-то рукодельник положит прод, то весь Сбер или любой другой банк не упадет и ты сможешь также переводить деньги за свой любимый калик 🚬. А вот какие-нибудь кредиты полежат в сторонке. То есть безопасненько с точки зрения отказов системы

🟢 Достаточно быстро катим фичи: утром продумали, днем напилили, на полдник протетсировали (шучу, лучшие тестировщики это пользователи), а вечерком катнули в прод. Не нужно ждать по 12 часов пока соберется build для твоего приложения, заедет в registry. А потом еще ждать ⌛⌛⌛ долгой раскатки

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

🟢Оптимизация БД: каждый сервис может работать со своей уникальной БД. Нужна тебе жесткая аналитика - колоночная БД, хочешь из коробки шардинг и все вот это - New SQL. Короче, не нужно ставить один комбайн Oracle, который на все случаи жизни


Ну а в следующий раз посмотрим на способ распила этого самого монолита и как его делать, чтобы не пришлось годами возиться с этой затеей 👋

Понедельник с новых знаний

А мы продолжим нашу серию постов про монолиты и микросервисы. Если не читал первые две части, то вот и вот

Значит, как пилим то? 🔜 Главная ошибка многих это подход "Ща сервисы главное по доменке вынести и все ок будет". Как говорится, a few moments later💛

Так что давай все по красоте распишем:

Шаг 1
Смотрим на логику нашей системы (бизнесово и технически).

На условном примере финтех-продукта:
- Принимаем платежи от соседней команды
- Проверяем платежки
- Ведем статистику по платежам в разрезе компании
- Дополнительная авторизация между сервисами

Эту всю красоту круто раскидать в каком-нибудь Miro. Пожалуйста, без UML🙏 А то таких коллег хочется с вертухи отработать

Шаг 2
Далее идем от данных

- Какие schema есть в БД. Каждая схема обозначает потенциальную принадлежность к отдельному домену. Или же, наоборот, ряд схем можно объеденить в одну
- На этом этапе нам нужно продумать, какие schemas могут жить вместе, а какие нет

Шаг 3
Детектим нарушения в запросах🚨

- Пишем а-ля QueryWatcher, чтобы обнаруживать JOIN из разных schemas. Именно те, которые хотим разнести в будущем
- В будущем у нас будут application level JOINs на месте этих DB level JOINs

Шаг 4
Сначала выносим core-сервисы, а потом продуктовые
- Сервисы авторизации
- Всякие сервисы для feature flags

Золотое правило: монолит общается с новыми сервисами, но не наоборот. Иначе создается распределенное месево

Так, кажется все? Нет, важно еще обсудить раскатку и тестирование этого чуда. Ну и еще пару моментиков. Увидимся в след посте👀

Хорошей недельки!✨

Финалочка про монолиты и сервисы

3 прошлые статьи можешь прочесть вот, вот тут и тут

А мы давай пройдемся по оставшимся шагам


Шаг 5
Мысль, которую нужно всегда держать в голове: если монолит большой и старый, то выносим функционал в сервисы as-is, то есть как есть. Я понимаю, что хочется сделать все сразу хорошо.

Но давай так: ставь 😭, если видел примеры перепилов монолита, которые растягивались на годы. Именно поэтому не нужно выпендриваться и пытаться сразу сесть на 2 стула.

Шаг 6
Банально, но факт - тестируем каждый шаг. Вынесли кусок функционала - запустили тесты

- Запускаем тесты в системе, чтобы проверить, что все гуд. Внутри микросервисов, внутри монолита, а также отдельные тесты у QA
- От компании к компании пирамида тестирования может отличаться, но в целом интеграционные тесты должны быть как внутри сервисов, так и отдельно (в проекте у QA)
- Если вдруг не шаришь про Пирамиду тестирования, то вот здесь небольшая статейка на этот счет: https://habr.com/ru/articles/672484/

Доп моментик:

А как мы будем делать роутинг трафика между монолитом и микросервисами? ➡️ Strangler Fig pattern: https://bool.dev/blog/detail/strangler-pattern


А еще можешь глянуть ретроспективу от AirBnb. Как они переписывали свою систему и чему научились: https://www.youtube.com/watch?v=yGOtTd-l_3E

Незнание этого принципа погубит твою распределенную систему

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

Проблема в том, что в распределённой системе такие расхождения быстро превращаются в хаос. Представь: один сервер думает, что уже завтра, а другой — что ещё вчера. Координировать данные становится невозможно.

Здесь появляется NTP (Network Time Protocol). Это протокол, который синхронизирует часы по сети. Работает он так:
🟡Ты стучишься в несколько NTP-серверов.
🟡Отбрасываешь “странные” ответы.
🟡Усредняешь оставшиеся и подправляешь свой локальный таймер.

Все серверы в мире связаны иерархией:
🟡Stratum 0 — атомные часы.
🟡Stratum 1 — напрямую синхронизированы с ними.
🟡Stratum 2, 3 и далее — постепенно получают время от верхнего уровня.
🟡Stratum 16 — значит, сервер несинхронизирован.

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

Например, у нас с тобой BIg Tech компанию по типу Uber, Yandex. Мы можем поставить свои атомные часы (stratum 0) и все остальные железки будут синхрониться с ними. Или же платить за атомные часами другим компаниям.

Кстати, если у тебя Mac, то в Date & Time можешь увидеть NTP сервер, к которому подключается твоя машина. Чаще всего это будут stratum 1 или stratum 2.

#distributed_systems #ntp

Факапы это нормально

Недавно смотрел одно интервью и задумался: почему все программисты только пишут о том, как у них всё круто взлетает, какие они супер‑пупер молодцы?

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

Взять хотя бы запуски того же SpaceX. В начале были одни провалы. И даже сейчас процент успешных запусков не 100.

А если говорить про знакомую прогу, то на собесе в любой Big Tech тебя спросят про ошибки, которые ты допускал, и как ты отрефлексировал их.

Я вот помню ситуацию в 2024 году: готовился запускать фичу в Такси. Нужно было проверить на одном небольшом городе, что всё точно ок. Ну, перепутал конфиги — и по итогу весь город остался без такси на 20 минут👀

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

Главное — делать выводы из своих ошибок.

Хорошего воскресенья!⭐️


PS: в комментах можешь поделиться своими факапами при разработке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

2️⃣ Доменыыы

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

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

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

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

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

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

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

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

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

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

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

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

4️⃣Что еще?

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


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

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

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

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

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

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


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

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


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

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

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

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

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


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

Зачем?

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

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


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

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

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

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

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


Финалочка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

#career #senior

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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