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

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


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