Всем спасибо за эфир!⚡️

Прикрепляю схему, которую объяснял.

А также ссылки:

Kafka scale up/down

1. Red Hat

2. Strimzi

Read your writes

1. Replication in distributed systems

2. Read your writes consistency

3. GitHub article

4. How to read your own writes


На следующий эфир приглашу гостя из западного Big Tech🧑‍💻
Анонс заранее сделаю


Можете также накидывать разные вопросы

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

Если когда-нибудь пользовался Т-Бизнес, то мог заметить вот такие fancy графики📊. Так вот, их когда-то делал я. Вернее даже так - было старое легаси и я переделывал с нуля все эти графики.

Уже чуешь подвох? Легаси, product manager хочет 100500 фичей в новых графиках. По итогу эта фича съела у меня месяц работы, а также я думал увольняться из-за постоянной смены требований у продакта, конфликтов с QA из-за разночтений в спеке и по факту🔫

Как бы я поступил сейчас:
✅ Написал RFC, где подробно указал бы продуктовые сценарии, чтобы продакт все изучил

✅ В этом же RFC нарисовал бы архитектуру приложения (про это еще скажу дальше)

✅ Возможно, даже спустился бы на уровень C3-C4, так как графиков очень много и стоит подумать на модульностью (ставь лайка, если понял, что дело пахнет GoF)

Архитектура
1. Кластер ClickHouse, к которому постоянно прилетают запросы на перерасчет. Запрос к CH были одним из самых лютых занятий, так как нужно было учесть тонну параметров (про CH сделаю отдельный пост)

2. Так как запросы тяжелые, то накатил слой кеширования, который время от времени обновлялся в background. А если кеш плохо себя чувствует, то fallback на CH. В этом нам поможет circuit breaker.

3. Лютая логика в Java коде: Strategy pattern, Facade, Template Method - это все использовал для создания модульности и легкого расширения (тут кста все четко сработало и новые графики заезжали как по рельсам)


В общем, вот так одна из самых прикольных задач на моей памяти чуть не погубила мою карьеру в Т-Банке. Относись внимательнее к проработкам и хотелкам бизнеса. Не бросайся сразу делать что-то, а продумай corner cases🤌

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

В общем завтра записываю первое и отдаю на монтаж.

К разговору про тему видео. Меня некоторые ребята спрашивают:

А что такого уникального во многих Big Tech компаниях? И почему ряд кандидатов не проходят испыталку.

Для начала глянь вот этот пост, в котором разложил важность выхода за рамки привычного "дали спеку -> написал код": https://t.me/system_design_algocode/16

А теперь давай раскрою на реальном примере. Вот человек сделал архитектуру сервиса X:

1. В данном сервисе очень много последовательных интеграций

2. Интеграция == проверка, что автомобиль не подходит нам для применения финального условия после всех проверок

3. Казалось бы, логично, что после каждой проверки стоит убирать автомобиль из общего набора, так как а) уменьшает нагрузку на внешние API б) ускоряет обход всех тачек


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

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

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

В то же время разработчик должен подробно расписать, а как будут обрабатываться более точечные кейсы (i.e. нужна ли пагинация и как ее будем делать). И все это делается в рамках технической проработки задачи: RFC, Design Doc - название разнится от компании.

А еще это помогает тебе развиваться как инженер и смотреть на задачу шире. Но об этом уже в видео. Скоро на экранах🖥


Ставь огонек, если ждешь🔥

Плохо спроектировал API - обрек себя на провал

Многие выглядят вот так, когда разговор затрагивает API🤦‍♂️

Недавно делали интеграцию с одним гос реестром. И как думаешь, что получали в поле message, если от API прилетала ошибка - Null Pointer Exception🖕

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


1. Разделяй ответственность API

Не нужно пихать в одну API создание пользака, кол-во подписчиков и так далее. Лучше сделай 2 органичные апишки

Bad:

{
"userId": 101,
"action": "createPost",
"content": "Сегодня чудесная погода!",
"mentionUsers": [102, 103],
"notifyFollowers": true,
"trackAnalytics": true
}

Good:

{
"userId": 101,
"content": "Сегодня чудесная погода!",
"visibility": "public" // можно указать "friends", "private" и т.д.
}

2. Обратная совместимость

Вот выкатил ты новую версию API и начал получать хейт в саппорт. В чем же проблема - breaking changes. Если твоя новая версия API не работает со старыми - смерть для продукта. Практически каждая новая версия должна работать со старой.

3. Тут же приправим все версионностью

Каждая значимо новая версия API должна выкатываться с новой версией: v1/system-design-course. Это позволит тем же версиям на мобилке делать плавные релизы и выводить из поддержки старые версии постепенно

4. Адекватные error message

Обрабатывай ошибки и возвращай понятные error messages, чтобы твои коллеги не гадали, а что не так. Также логируй все

try {

} catch (Exception404 ex) {
    logger.error("Error from api: %s", ex)
    return Exception("Not found resource")
} catch (Exception500 ex) {
...

5. Internal api - вещь

Обычно API можно разбить на 2 части: внешние и внутренние.
Часто внутренние делаются как v1/internal/system-design. Это позволяет настраивать внутренние прокси системы на другой формат auth


6. Нагрузка на API

Под этим я имею в виду пагинацию, rate limiters, load shedding и так далее. API - первая линия твоей системы. Нужно продумать про нагрузку и перформанс. А иначе есть риск проснуться ночью от звонка обезьяны🐒

================
Ниже закину еще пару статеек, где можешь побольше узнать про тонкости работы с API:

- Как Slack дизайнит API: https://slack.engineering/how-we-design-our-apis-at-slack/
- Как Stripe защищает свои API от DoS: https://stripe.com/blog/rate-limiters


Ставь 🙈, чтобы на следующем дежурстве тебе не звонил pager

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

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


Вот ты пришел на новую работу и видишь его: монстра с 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 в ❤️


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