Обзор с выбором ответа по всему юниту фреймворка интервью: прояснение требований и паттернов доступа, оценка, что меняет дизайн, разделение HLD и deep-dive, поиск узкого места с называнием трейдоффов.
SDSenior◷ 13 min
Уровень
ОсновыJuniorMiddleSenior
Шесть вопросов, что режут весь фреймворк интервью насквозь. Каждый — это решение у доски: что спросить до рисования, какое число оценить, во что копнуть, где узкое место — не определение для зубрёжки. Отвечай так, будто интервьюер высматривает сеньорский сигнал.
Подтверди, что можешь прогнать фреймворк от начала до конца: проясни требование, что реально меняет дизайн, оцени только важное число, отдели чистый HLD от настоящего deep-dive, найди единственное связывающее узкое место и назови трейдофф с его ценой.
Викторина
Completed
Дано «спроектируй чат» и больше ничего. Какой вопрос сильнее всего меняет архитектуру и должен идти первым?
Heads-up Язык — деталь реализации, не двигающая высокоуровневую архитектуру. Нефункциональная цель (согласованность/задержка) толкает к fan-out-и-кэшу против строгой координации — спрашивай её первой.
Heads-up Число таблиц — следствие модели данных, которая следствие сущностей и паттернов доступа. Нельзя оценить схему до фиксации целей согласованности/задержки, формирующих дизайн.
Heads-up Выбор облака редко меняет архитектуру на этом этапе. Нагруженный ранний вопрос — нефункциональная цель: согласованность и задержка.
Викторина
Completed
Социальная лента читается ~100:1 к записям. Что этот паттерн доступа прямее всего оправдывает до того, как нарисована коробка?
Heads-up Это оптимизирует редкую операцию. Когда чтений в 100× больше, ты предвычисляешь и кэшируешь путь чтения, а не ускоряешь нечастые записи.
Heads-up Отношение 100:1 ничего не говорит про строгую репликацию записей, что лишь замедлило бы записи. Оно указывает на оптимизацию чтений — кэш и fan-out — первым делом.
Heads-up Это один из самых релевантных фактов: read-heavy паттерн оправдывает кэш и предвычисленные чтения. Паттерн доступа, не сущность, выбирает путь чтения.
Викторина
Completed
Оценка до одной значащей цифры: 50M DAU, каждый по 2 поста/день, чтений ~50× постов. Какое число первым меняет дизайн и на что?
Heads-up ~1 000 записей/с (≈3K на пике) комфортно под потолком низких тысяч одной primary — это НЕ форсирует шардинг пока. Число, меняющее дизайн, тут — ~150K пиковый read QPS, что форсирует кэш.
Heads-up Хранилище текста может быть скромным, но если есть медиа, оно доминирует на порядки — и в любом случае ПЕРВОЕ число, меняющее дизайн, это ~150K пиковый read QPS, форсирующий кэш/fan-out путь.
Heads-up Размер ответа — для полосы, считается позже. Read QPS идёт прямо из активности ÷ секунды и уже форсирует решение о кэше/fan-out до того, как ты размеряешь полосу.
Викторина
Completed
Ты нарисовал чистый HLD из пяти коробок, осталось 30 минут. Какой ход с наибольшей ценностью?
Heads-up Широта — ставка на входе, а лишние коробки — обуза, что придётся защищать. Интервью выигрывают в глубине: проинженерь сложный компонент, а не раздувай HLD.
Heads-up Оценка уже пометила сложную часть. Перевывод жжёт бюджет на deep-dive — часть, доказывающую, что ты умеешь инженерить, не только оценивать.
Heads-up Эта обобщённая скороговорка читается как поверхностность и сигналит, что про задачу сказать нечего. Иди глубоко по сложному компоненту; ops коротко в конце, если вообще.
Викторина
Completed
Кластер БД показывает 40% средней CPU, но пользователи ловят таймауты на запросах к одному популярному аккаунту. Каково узкое место и почему среднее вводит в заблуждение?
Heads-up Среднее лжёт. Среднее по кластеру 40% может прятать один шард на 99% (данные популярного аккаунта). Система встаёт на самом горячем ресурсе независимо от среднего — это узкое место, на которое указывают таймауты.
Heads-up Симптом (таймауты БД, низкая средняя CPU БД) указывает на неровную нагрузку внутри базы — горячий шард — не на сервис-слой. Добавить CPU сервису — расширить не связывающий ресурс.
Heads-up Низкая средняя CPU с локализованными таймаутами прямее всего указывает на горячий шард/ключ, перекосивший нагрузку, не на насыщение сети. Урок: среднее вводит в заблуждение — ищи самый горячий ресурс.
Викторина
Completed
На вопрос «а если трафик вырастет в 10×?» какой ответ показывает сеньорское рассуждение об узком месте, чему учит юнит?
Heads-up Мидловый рефлекс: правда, но не назван КАКОЙ ресурс ломается первым. Stateless-слой масштабируется out тривиально; реальное узкое место смещается на stateful-ресурс. Назвать связывающее ограничение и его починку — сеньорский сигнал.
Heads-up Ни один дизайн не масштабируется бесконечно — всегда есть следующее узкое место (primary на запись, горячий шард, кэш, переросший RAM). Заявить, что ничего не меняется, показывает, что ты не нашёл, куда смещается ограничение при 10×.
Heads-up Язык редко адресует связывающее ограничение, что при 10× почти всегда stateful-ресурс, не CPU сервис-слоя. Сеньорский ход — найти этот ресурс и починить именно его.
Вспомните перед уходом
01
Почему нефункциональная цель, не список фич, — нагруженный ранний вопрос?
02
Как обрабатывать «10× трафика» как процедуру, а не рефлекс?
Итог
Сквозная линия — что интервью по системному дизайну это одна повторяемая процедура, и эти шесть вопросов тестируют каждый шаг. Проясни нефункциональную цель, что реально меняет дизайн (согласованность/задержка решает fan-out-и-кэш против координации), и прочти паттерн доступа (100:1 read-heavy → предвычисленный кэшированный путь чтения). Оцени только важное число — ~150K пиковый read QPS, что форсирует кэш, не скромный темп записи и не мелочи. Нарисуй чистый HLD быстро, затем потрать бюджет на настоящий deep-dive реально сложного компонента, а не раздувай число коробок. Найди узкое место — единственный самый горячий ресурс, что прячет средняя утилизация (кластер 40%, плавящийся на одном шарде) — и обрабатывай «10×» пересчётом, называя новый связывающий ресурс, его починку и трейдофф. Сигнал сеньорности под всем этим: называй конкретный ресурс и цену каждого выбора, никогда просто «добавь серверов».
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.