Как функциональные требования могут убить твою систему?🔪

Представь, что ты разработчик в Big Tech. И вот тебе выдали задачу, где общие требования:

1️⃣ DAU 50 mln
2️⃣ Важна минимальная задержка между обновлением данных в источнике и в нашей системе
3️⃣ В нашей системе любые задержки неприемлемы, так как для сервиса критичен response time


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

И вот ты садишься, считаешь нагрузку, пытаешься что-то сделать день/два/три. А еще ты нервничаешь, что, наверное, не вывозишь задачу и вообще какое тебе место в Big Tech!😨

Но на самом деле все проще: нужно оспаривать бизнес по поводу их требований.

Как гласит CAP-теорема: невозможно сделать систему одинаково согласованной и доступной.

Так и здесь: нужно делать выбор — хотим ли мы 100% точности в системе или же нам важнее скорость. Так как скорость страдать не может, то жертвуем точностью🎯

А как аргументировать свой подход? — Об этом расскажу в следующей части🔜

#функциональныетребования #нагрузка

А как говорить с Бизнесом, когда требования — фантастика? 🤯

Привет! В прошлый раз мы залипли на том, что хотеть 100% согласованности данных + нулевых задержек + бесконечной доступности — это как мечтать о вечном двигателе. Значит, нужно идти к Бизнесу и... спорить😱

Но кто этот ваш "Бизнес"? Чаще всего на другом конце — BizDev (Business Development). Их задача — растить рынок, завоевывать клиентов, заключать партнерства и ставить амбициозные цели. Технические детали — не их профиль (хотя бывают и приятные исключения!).

Проблема: Как донести до BizDev'а, что его "просто сделайте" — это путь в технический ад? 🤔 Всё зависит от его "технической просвещенности":

1. Тип "Вообще Не Шарю":

Как выглядит: Глаза стекленеют при словах "база данных", "репликация". Для него система — черный ящик: "Закинул данные -> получил результат".

Как аргументировать:

🔹 Аналогии из жизни: "Представь, ты хочешь, чтобы курьер мгновенно доставлял пиццу в любую точку города, абсолютно горячей, и при этом стоил копейки. Так не бывает? Вот и с данными так же: скорость, точность, цена (ресурсы) — выбирай два".

🔹 Фокус на бизнес-последствиях: "Если мы попробуем сделать именно так, как в требованиях, система будет падать каждый час, и пользователи уйдут к конкурентам. Готовы ли мы к такому риску?"

🔹 Простота: Никаких "CAP", "Paxos" или "кворумов". Только суть: "Скорость или точность? Выбирай приоритет".


2. Тип "Чуть-Чуть Шарю":

Как выглядит: Знает слова "API", "база", "нагрузка", но глубоко не копает.

Как аргументировать:

🔹 Упрощенная визуализация: Схемка потока данных, где видно узкое горлышко или источник задержек. "Видишь эту стрелочку? Вот здесь при таких требованиях будет пробка".

🔹 Оценка в цифрах (очень грубо): "Ты хочешь обновлять данные для 50 млн DAU мгновенно. Даже если мы сделаем магию и обновим 1 запись за 1 мс, на всех это займет ~14 часов. Это реалистично?"

🔹 Предложение конкретных альтернатив: "Мы не можем гарантировать мгновенную точность для всех. Но можем: а) Гарантировать для премиум-пользователей; б) Гарантировать точность с задержкой 5 сек для всех; в) Гарантировать, что 99.9% данных будут точны через 10 сек. Что важнее для реального сценария?"


Итого: Независимо от типа BizDev, твоя ключевая задача как инженера — перевести технические ограничения на язык бизнес-рисков и возможностей. Умение делать этот перевод — критически важный навык, который часто приходит с опытом. Многие junior-middle разработчики фокусируются только на технической стороне, упуская бизнес-контекст.


В конце накину еще пару примеров:

🔹 Вместо “из-за кеширования могу быть неточности в данных” → “Чтобы ответить пользователю максимально быстро, мы используем предварительно подготовленные данные. Это может приводить к небольшим задержкам в актуальности информации, но критично ускоряет работу сервиса.” (Фокус на цели "скорость" и компромисс)

🔹 Вместо “У нас Postgres в этих сервисах, поэтому мы не сможешь просто так шардировать” → “Текущая архитектура хранения данных оптимизирована под надежность и сложные запросы. Ее масштабирование для таких нагрузок потребует значительных изменений и времени, так как простое ‘разделение’ данных здесь неприменимо.” (Фокус на последствиях - время/ресурсы и причина - "надежность/сложность запросов")"

#bizdev #коммуникации #карьера #softskills

Ну, лента😅

Казалось, есть лента в любой социальной сети. Что там сложного: берёшь посты юзеров и накидываешь в общий пул постов. А ещё какую-нибудь рандомную сортировку — вообще великолепно.

Но не тут-то было✋

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

А ещё есть много способов доставки этих постов в ленту. Например, сравним 3 подхода:

- Храним все посты юзеров в кеше у Feed Service. При запросе ленты получаем подписчиков юзера и делаем feed-merge (подготовка ленты).

- Храним посты в кеше у Feed Service только для активных пользователей. А если неактивный: получить подписчиков и затем выгребать посты из сервиса постов.

- Храним посты в кеше у Feed Service, но делаем fallback strategy на Post Service, чтобы в случае отказа ленты у нас был запасной вариант. И ещё сюда можно прикрутить circuit breaker.

В чём ➕ и 〰️ подходов? Для первого требуется гигантский RAM, но меньше response time. Для второго меньше RAM, но потенциально выше response time. Третий более надежный, но требует более сложной логики и долгой настройки.

А ещё можно поставить кеш перед Feed Service, чтобы первые 10 постов были всегда готовы (допустим, для всех пользаков). И таким образом мы можем сначала отдать из кеша, а попутно запустить поток готовить ленту дальше.

Как ты видишь, даже у 1 элемента в системе можно набросать множество вариантов. Но у каждого будут свои сильные и слабые стороны. Это называют trade-off📎


В след посте расскажу, а почему важно уметь прорабатывать разные варианты, если ты хочешь получить senior и выше👆

#лента #архитектура

Я считаю, что программисты должны только писать код🖥

Смелое заявление, которое делают некоторые люди. Давай посмотрим на это с разных сторон.

Если ты не прорабатываешь задачу, не рисуешь архитектуру от и до, не выбираешь подходы, не набрасываешь product manager'у контраргументы на его предложения — ты отвечаешь только за свой маленький кусочек. И если другие звенья уйдут в отпуск или уволятся, тебе будет сложно — и оценка на ревью окажется не такой прекрасной.

А что, если ты захочешь попасть в западный Big Tech или создать свой проект? Тебе нужно уметь смотреть на проект шире, чем «вот ТЗ — напиши по нему».

Помни, что работа должна развивать тебя как специалиста, чтобы ты не оказался позади рынка. А если ты бездумно выполняешь задачи по ТЗ, то о каком развитии может идти речь❓

Если согласен, то ставь палец вверх👍

#архитектура #yandex

Какой же алгоритм для прохождения system design?🔧

Очень часто меня просят рассказать про этапы собеса по system-design. А также, что стоит делать на каждом.

Я решил подготовить ультимативный шаблон для этой секции, где будут шаги и примеры.

Забирай по ссылке

Если оказалось полезным, то ставь ❤️

#собес #шаблон

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

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

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

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 - все были монолитами с самого начала. И только потом решили перейти на микросервисную архитектуру


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