---
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, у других названия отличаются):

| Уровень | Кто это | Комментарий статьи |
|---------|---------|--------------------|
| L3 | джун | уровни ниже L3 — не для программистских должностей |
| L4 | мидл | 3 месяца подготовки по плану статьи |
| L5 | сеньор | — |
| **L6** | «этакий тимлид» | **можно «расколоть» просто отличной подготовкой** — без индустриальных достижений |
| L7+ | — | без достижений в индустрии попасть невозможно |

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

- **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):

| Число (статья) | KB §1.2 | Вердикт |
|----------------|---------|---------|
| Сжать 1 КБ (Zippy = Snappy) — 0.003 мс | сжатие 1 КиБ ~3–10 мкс | ✓ совпадает |
| Послать 1 КБ по 1 Gbps — 0.01 мс | 2 КиБ → 20 мкс | ✓ (та же удельная скорость) |
| Прочитать 4 МБ из памяти — 1 мс | RAM ~4 ГиБ/с | ✓ согласуется |
| Прочитать 4 МБ с SSD — 20 мс (~200 МБ/с) | SSD ~1 ГиБ/с, NVMe до 3–7 | ~ консервативно, SATA-эпоха; для NVMe статья занижает |
| Прочитать 4 МБ с HDD — 80 мс (~50 МБ/с) | HDD 30–100 МиБ/с | ✓ в диапазоне |
| Disk seek — 10 мс | 10 мс | ✓ |
| **Раундтрип внутри датацентра — 150 мс** | в ДЦ ~0.5 мс; **150 мс — это через океан** | ❌ **ошибка статьи** (перепутаны ДЦ и океан). Учить по KB, не по статье |
| Пропускная способность внутри ДЦ ~100 Gbps | NIC 1–10 Gbps у ноды, агрегат ДЦ выше | ~ имеется в виду агрегат, не нода |

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

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

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

| Константа | Значение | Зачем |
|-----------|----------|-------|
| Cassandra: свободное место под компакцию | ~30 % | LSM не может работать «под завязку»; диск 2 ТБ → планируй ~1.4 ТБ данных |
| Утилизация диска под БД | ~85 % | остальное съедает ОС |
| Смертность дисков | 3–5 % в год | закладывать резерв, не «ровно N дисков» |
| Cassandra: размер ноды | лучше всего 1–2 ТБ | «тормозит на дисках больше 2 ТБ» |
| Cassandra: нагрузка на ноду | 10–15 тыс. запросов, рост линеен по нодам | делитель для расчёта кластера (аналог шага 6 KB §2.1) |
| Память сервера | 100–150 ГБ доступной | делитель для memory-bound расчётов |
| 1 Gb/s | 125 МБ/с | перевод бит↔байты при bandwidth-расчётах |
| Видео | ~10 МБ/мин; 720p — 1.5 Mbps; 360p — 150 Kbps | для медиа-задач (у нас — `../classic-designs.md` §4) |

Применение на секции: после «сырого» расчёта 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)