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

Представь, что ты разработчик в 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. А также, что стоит делать на каждом.

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

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

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

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