title: Конспект материала 17 — «Проходим L6 интервью на System Design в FAANG» (habr 655663) source: https://habr.com/ru/post/655663/ author: анонимный автор (RU-эмигрант, собирал материалы по собеседованиям в FAANG несколько лет), 15.03.2022 конспект: подготовлено 2026-09-17, TASK-45.21; статья — про планку L6 и подготовку к ней: уровни, глубина, back-of-envelope; три расчёта статьи проверены, найдены две арифметические ошибки автора (§4, §5) статус: взгляд «планки» — не формат секции, а критерий качества ответа (L6 = глубина + декомпозиция + числа как инструмент поиска узкого места); формат и этапы у нас уже закрыты methodology.md §1 и Поломодовым (lsd-polomodov-guide.md)

Материал 17: «Проходим L6 интервью на System Design в FAANG» (habr 655663)

Статья кандидата, который готовился к System Design Interview в FAANG и собрал гайд «как дорасти до L6». Для нас это не ещё один формат секции (формат Яндекса и Поломодова уже разобран), а калибровка планки: чем ответ уровня «тимлид» отличается от ответа «сеньора», и что именно качать. Две вещи в статье уникальны против наших материалов: (1) метод «лестницы глубины» при подготовке и (2) операционные константы sizing (компакция Cassandra, утилизация диска, память на сервер) — §6.

Позиция в треке: индекс learn-system-design-index.md ставит материал в P2, слот 22.09 (45 мин) — после Поломодова и моков, как «взгляд на senior-планку».

1. Уровни FAANG и критерий L6

Система уровней (за стандарт взят Google, у других названия отличаются):

Ключевые тезисы про планку:

• L6 — это про глубину. «Чем глубже вы можете уходить на интервью, тем более высокий уровень вам могут дать». Глубина = способность объяснить компонент на уровень-два ниже интерфейса (§3).
• Декомпозиция вместо квадрата. «Если во время дизайна вы нарисуете на доске один большой квадрат с припиской "Server" вместо многих компонентов — пойдете джуном». Уровень считывается прямо по детализации схемы.
• Подготовка коррелирует с уровнем: 3 месяца плана → скорее L4, 9+ месяцев → L6. «Не нужно быть гением, просто трудолюбивым человеком и знать английский».
• Важно для калибровки ожиданий: интервью не требует делать всё это руками — «про них нужно только рассказать ртом». Совпадает с калибровкой Gabbard (jackson-gabbard-ep06.md).

Соотнесение с нашей ситуацией: в Yandex Codenv секция — этап 2 на позицию руководителя группы разработки backend; по шкале FAANG это примерно L6-планка (тимлид). Значит ориентиры статьи — глубина, детальная декомпозиция, уверенные расчёты — это ровно та планка, под которую заточен план В (../methodology.md §5).

2. Формат секции: что проверяют

• SDI длится 45 минут, иногда их несколько («за эти полтора часа…» — т. е. типично пара секций). Наша секция — час, формат Яндекс (yandex-564132.md) слоёный, из 6 этапов.
• FAANG оперирует в масштабе всего земного шара: «десятки и сотни миллионов пользователей», задачи масштабирования, прикидывание мощностей, размеров диска, состояния гонки.
• Проверяется умение раскладывать сложную систему на компоненты, оперируя знаниями о возможностях разных систем и БД — «даже если вы никогда не применяли эти знания на практике».
• Рекомендация: все материалы читать на английском, чтобы на интервью оперировать корректными терминами.

3. Путь подготовки: материалы и «лестница глубины»

Порядок источников по статье (что даёт каждый):

1. DDIA (Клеппман, «Высоконагруженные приложения») — «половина работы», читать медленно, без пропусков. Часть 1 — выбор правильных БД; часть 2 — страхи шардирования и выбор репликации; часть 3 — как склеить большую систему из маленьких (главное — разделение системы записей и производных данных). Критерий готовности: «проснуться посреди ночи и объяснить, как LSM-деревья используют красно-черные деревья для сортировки лога в памяти и зачем» (в статье опечатка «LSTM»). У нас карта и порядок чтения — ddia-map.md + ../knowledge-base.md §12; выводы автора по трём частям совпадают с нашей картой.
2. Курс Grokking the system design interview — «запомнить мельчайшие детали большинства решений»: детали важнее общей картины. Пример: дизайнишь typeahead — должен рассказать про экспоненциальное скользящее среднее (EWMA) для взвешивания выдачи. Аналог по нашей базе — ../classic-designs.md: запоминаем конкретные механизмы, не только скелет.
3. Видео о реальных системах (InfoQ, @scale): Nathan Bronson — Tao и кэши; Nishtala — memcache в Facebook; Kulkarni — Facebook Live; Aroskar — Zuul Push; Raffi Krikorian — Timelines at Scale (там те же расчёты в деле, §4). Для нас — фонд после секций: глубина под следующие этапы и интервью.
4. SRE-книга Google — глава NALSD (Non-Abstract Large System Design): «понять и запомнить чуть ли не наизусть, особенно часть про оценки размеров, ресурсов, времени». Наш аналог этого блока — ../knowledge-base.md §1–2 + ../methodology.md §2.

Главный метод статьи — лестница глубины:

Не пропускай непонятное. В видео про Zuul упомянули Apache Netty — прочитай, пойми. Пойдите глубже — пойми epoll и его красно-черные деревья. Ещё глубже — TIMED-WAIT трюк в TCP, который сохраняет вебсокет-соединения. Упомянули, что балансировщики не справляются с вебсокетами — почему? Разберись!

Это ответ на вопрос «где копать глубже» из индекса подборки: глубина наращивается не «ещё одной темой», а раскопками вниз от каждого встреченного термина. Цепочка Zuul → Netty → epoll → TCP TIME-WAIT — образец того, как из одного доклада вырастает веер тем.

4. Ход решения: три расчёта из статьи (проверено)

Цель чисел по статье — не блистать математикой, а найти, чем ограничена система (диском? CPU? памятью?) и как её масштабировать: «как только вы начнете чувствовать это, вы сможете дизайнить сервисы с разными техниками масштабирования». Правила: степени десятки (практика NALSD), всегда тащить единицы измерения (байт/пост, пост/лента) и сокращать их, считать рано — «чтобы прочувствовать ограничения и заранее спланировать масштабирование». Это ровно наш метод ../knowledge-base.md §2.1 («допущение → формула → число → вывод»).

Пример 1: лента миллиона людей — влезает в память?

10 постов на ленту сходу, храним только ID по 8 байт (redis):

• 8 Б/пост × 10 пост/лента = 80 Б/лента
• 10^6 лент × 80 Б/лента = 8×10^7 Б = 80 МБ → легко помещается в память. Сервис с такими параметрами можно не масштабировать по storage вовсе.

Пример 2: лента 500 миллионов — сколько машин?

800 постов в ленте, 8-байтный ID, фактор репликации 3, машина 64 ГБ памяти, из них пользоваться можно 50 ГБ:

• 8 Б/пост × 800 пост/лента = 6.4×10^3 Б/лента
• 5×10^8 лент × 6.4×10^3 Б/лента = 3.2×10^12 Б ≈ 3 ТБ
• × 3 (репликация) ≈ 10 ТБ
• Машины: 10 ТБ / 50 ГБ = 10×10^3 ГБ / 50 ГБ = 200 машин. ⚠️ Статья пишет «10 / 50 = 2×10^3 = 2000 машин» — арифметическая ошибка ровно того типа, против которого статья предупреждает: единицы уронили (ТБ поделили на ГБ как на «штуки»). Верный ответ — ~200 машин. Иллюстрация силы правила «единицы с собой»: ошибается даже автор гайда.

Вывод примера (по статье): сервис ограничен по памяти — масштабируется добавлением нод с RAM, отсюда и техника масштабирования.

Пример 3: логгирование 100 млрд событий в день — сколько QPS?

Переводим в секунды сразу, сутки округляем до удобного:

• 100×10^9 событий/день / 86 400 с/день (≈8.6×10^4) = 10^11 / 8.6×10^4 ≈ 1.2×10^6 событий/с = 1.2 млн QPS
• Дальше «возьмите удобное число, которое похоже на то, сколько выдержит одна машина, и поделите» — у нас это шаг 6 метода KB §2.1 (типовое приложение ~1–10 тыс. RPS/ноду) и константы §6 ниже (Cassandra: 10–15 тыс. запросов/ноду).

Дополнительные правила из статьи: «10 секунд примерных расчетов должны подтвердить», влезает ли что-то в одну машину (обычно в память); обычно получается несколько сервисов с разными механизмами масштабирования — считать каждый.

5. Числа статьи против нашей KB §1.2

Список «чисел, которые можно использовать без доказательств», сверен с ../knowledge-base.md §1.2 (latency-таблица у нас — объединённая из Primer Appendix и источника 4):

Урок сверки: даже «проверенные» шпаргалки содержат ошибки (здесь — перепутанный round-trip и потерянный порядок в делении ТБ/ГБ, §4). Числа держим в одном месте — KB §1–2 — и оттуда же тренируем (протокол ../methodology.md §6).

6. Операционные константы sizing (уникальное статьи)

То, чего не было в Primer Appendix и других наших источниках, — эксплуатационные поправки к расчётам (когда считать «сырые» байты и делить на размер машины, этого не хватает):

Применение на секции: после «сырого» расчёта storage/memory проговорить поправку («×3 репликация, под компакцию оставим 30 %, значит реальный парк — вот такой»). Одна фраза, а звучит как опыт эксплуатации. Ссылка: DataStax capacity planning (числа для Cassandra и других БД).

7. Выводы для нашей подготовки

1. Планка считывается по схеме и глубине. Детальная декомпозиция (никаких квадратов «Server») + способность уйти на уровень вниз по любому нарисованному компоненту = ответ уровня L6/тимлид. Наш слоёный формат из 6 этапов (../methodology.md §1) этому и учит; при self-review добавляем вопрос «могу ли я по каждому блоку схемы рассказать на уровень глубже?».
2. Числа — инструмент поиска узкого места, не украшение: расчёт → «ограничено памятью/CPU/диском/QPS» → отсюда техника масштабирования. Это усиливает этап 5 (ресурсы и узкие места): вывод расчёта всегда заканчиваем классификацией лимита.
3. Лестница глубины — метод после секций. До слотов 18–22.09 новые темы не открываем (правило индекса: «до ближайшего слота ничего учебного нового»); но в фон и на следующие этапы — раскопки вниз от каждого непонятого термина (Zuul → Netty → epoll → TIME-WAIT), а не расширение списка тем.
4. Операционные константы §6 — взять в оборот на этапе sizing: компакция/репликация/смертность дисков/память на сервер — превращают «байты в ТБ» в «парк машин», и звучат как production-опыт.
5. Сверка чисел обязательна. В статье две ошибки (RTT ДЦ = 150 мс; 2000 вместо 200 машин) — источник правды по числам у нас один: KB §1–2, тренировки только по нему.
6. Материалы статьи маппятся на наши: DDIA → ddia-map.md (выводы по частям совпадают), Grokking → ../classic-designs.md (детали решений), NALSD → KB §1–2 + ../methodology.md §2, видео о реальных системах → фонд после секций. Ничего до слотов добавлять не нужно — план В (../methodology.md §5) уже включает этот конспект на 45 мин в вс/пн перед слотом 22.09.

Связанные документы

• ../methodology.md §5 (план В: этот материал — 45 мин в вс 21.09), §6 (протокол тренировок, куда идёт «глубина на уровень ниже» в self-review)
• ../knowledge-base.md §1–2 (числа и back-of-envelope — источник правды), §12 (карта DDIA)
• ../classic-designs.md — аналог «Grokking»: детали классических решений
• ddia-map.md — порядок чтения DDIA (выводы статьи по частям совпадают с картой)
• lsd-polomodov-guide.md — формат секции глазами интервьюера; jackson-gabbard-ep06.md — калибровка «рассказать ртом, не делать руками»
• learn-system-design-index.md — место материала в подборке (P2, слот 22.09)