Читай артефакты реального интервью — хелпер оценки, заметку требований, расчёт ёмкости, конфиг, что кодирует трейдофф — и рассуждай, как сеньор: какое число меняет дизайн, что конфиг отдаёт, куда смещается узкое место.
SDSenior◷ 14 min
Уровень
ОсновыJuniorMiddleSenior
Фреймворк живёт в числах и конфиге, не в прозе. Оценка, что переводится в число серверов, заметка требований, что прячет пропущенную цель, конфиг, что молча кодирует трейдофф. Читай каждый артефакт, делай арифметику и рассуждение в уме и выбирай ответ, на который сеньор подписался бы у доски.
Практикуй петлю, что прогоняешь у доски: найди число, что меняет дизайн, заметь пропущенное требование, переведи нагрузку в ёмкость и прочти, что конфиг отдаёт — выбирая ход, что поддерживают арифметика и трейдофф.
Читая до одной значащей цифры, какое выходное число первым меняет дизайн и на что?
Heads-up ~1 000 записей/с (≈3K на пике) комфортно под потолком низких тысяч одной primary — шардинг пока не форсирован. Число, меняющее дизайн, — ~150–200K пиковый read QPS, форсирующий кэш.
Heads-up Догадки на уровне порядка — ровно то, что меняет дизайн: ~150–200K пиковых чтений против ёмкости одной БД — явное пересечение порога, форсирующее кэш/fan-out путь. Вся работа оценки — это вскрыть.
Heads-up ~3 000 записей/с — ровно у, а не за пределом комфортных низких тысяч одной primary — на грани, стоит следить, но не первое, что меняет дизайн. ~150–200K пиковый read QPS меняет, форсируя кэш.
Сниппет 2 — заметка требований
# требования, зафиксированные до рисованияfunctional: - пользователи постят сообщения - пользователи читают лентуnon_functional: scale: 50M DAU latency_p99_read_ms: 150 # consistency: <-- не зафиксирована availability_slo: "99.9%"
Викторина
Completed
Каков самый последствийный пробел в этой заметке требований и почему он важен до рисования?
Heads-up Пропущена цель согласованности, и она нагруженная: терпящая устаревание даёт fan-out и кэш; строгая свежесть форсирует координацию. От неё зависят две разные архитектуры, поэтому её надо зафиксировать до рисования.
Heads-up Язык не меняет высокоуровневую архитектуру. Последствийный пробел — цель согласованности, что решает fan-out-и-кэш против координации — фиксируй её, не язык.
Heads-up Число сервисов — следствие дизайна, не входное требование. Пропущенный вход, что меняет дизайн, — цель согласованности.
Сниппет 3 — расчёт ёмкости
peak_read_qps = 200_000per_node_qps = 8_000 # точка изгиба кривой очередейcache_hit_rate = 0.90origin_qps = peak_read_qps * (1 - cache_hit_rate)nodes = -(-origin_qps // per_node_qps) # деление с округлением вверхprint(origin_qps, nodes) # что напечатает и что обоснует?
Викторина
Completed
Что это напечатает и какое решение дизайна обоснует?
Heads-up Расчёт применяет 90% попаданий: origin видит 200K × 0,10 = 20K/с, не 200K. Это ~3 узла — а разрыв с ~25 узлами без кэша ровно то, что обосновывает кэш.
Heads-up Провижининг origin на полные 200K сводит на нет смысл кэша и тратит флот. Размеряй origin под трафик промахов (20K → ~3 узла плюс запас); отдельно обеспечь плавную деградацию при отказе кэша.
Heads-up Это догадка уровня порядка, чего достаточно: при ~90% попаданий origin видит ~20K/с → ~3 узла. Суть в том, что кэш превращает флот ~25 узлов в горстку — разница, меняющая дизайн.
Сниппет 4 — конфиг, что кодирует трейдофф
# путь чтения лентыread_from: cachecache_ttl_seconds: 30on_cache_miss: read_replica # async-реплика, может отставать от primarywrite_path: fan_out_on_write_async
Викторина
Completed
Какой трейдофф кодирует этот конфиг и как ты сформулируешь его интервьюеру?
Heads-up Кэш с TTL 30с плюс async-реплика и async fan-out — противоположность строгой согласованности: он намеренно допускает устаревание. Честная формулировка называет это окно устаревания ценой задержки чтения и доступности, что он покупает.
Heads-up Каждый кэш кодирует трейдофф. Этот покупает задержку чтения и доступность, но стоит свежести (окно устаревания ~30с+) плюс заботы об инвалидации и thundering herd. Подать его строго лучшим — вернейший знак, что не продумал.
Heads-up Async fan-out не замедляет путь записи (он async); реальная цена — устаревание на чтениях: лента может отставать на десятки секунд. Назови трейдофф согласованности — он тут и важен.
Вспомните перед уходом
01
По выходу хелпера оценки как заметить число, что меняет дизайн?
02
Как перевести hit rate кэша в число origin-узлов и что обосновывает результат?
03
Как вычитать трейдофф из конфига и как его сформулировать?
Итог
Каждый шаг фреймворка проявляется в артефактах, что ты читаешь у доски. Хелпер оценки выдаёт число, что либо пересекает порог (~150–200K пиковый read QPS форсирует кэш/fan-out путь), либо нет (скромный темп записи ничего не меняет) — читай до одной значащей цифры и найди то, что двигает дизайн. Заметка требований судится по пропущенному: брошенная цель согласованности нагруженная, ведь терпимость к устареванию решает fan-out-и-кэш против координации. Расчёт ёмкости переводит нагрузку в ёмкость — 90% попаданий кэша превращают флот ~25 origin-узлов в ~3, что ровно обосновывает кэш — и ты всё равно размеряешь RAM кэша и страхуешься, чтобы он не стал SPOF. Конфиг молча кодирует трейдофф (TTL + async-реплика + async fan-out — это согласованность-в-конечном-счёте), и сеньорский ход — назвать цену (окно устаревания) и границу, где ты перевернул бы его (транзакционные данные). Читай числа, делай математику, называй решение и его цену — это и есть фреймворк в действии.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.