title: Конспект источника 2 — System Design Primer, Appendix (числа и список вопросов) source: https://github.com/donnemartin/system-design-primer/blob/master/README.md#appendix author: Donne Martin (system-design-primer, раздел Appendix) конспект: подготовлено 2026-09-17, TASK-45.6; числа — дословно из источника; мнемоники и приоритеты тренировки — наши дополнения статус: эталонный справочник чисел; сжатая экзаменационная версия — ../knowledge-base.md §1 (учить по ней, по этому файлу — сверяться и запоминать контекст)

Источник 2: System Design Primer — Appendix

Appendix — это три части: (1) таблица степеней двойки, (2) «Latency numbers every programmer should know» с производными метриками, (3) список типовых дизайн-вопросов со ссылками на разборы. Первые две части — сырьё для этапа 5 секции (оценка ресурсов и узких мест): интервьюер из статьи Яндекса прямо требует «latency numbers вспомнить обязательно». Третья часть — меню задач для тренировочных раундов и источник вероятных «доп. вопросов».

Связь с подготовкой: ../methodology.md §5 (слот 3 плана — 45 мин на числа), ../knowledge-base.md §1–2 (сжатая версия + back-of-envelope), ../classic-designs.md (на какие вопросы уже есть разборы).

1. Powers of two (таблица степеней двойки)

Дословно из источника:

Что из этого реально звучит на секции:

• Ключевое приближение: 2^10 ≈ 10^3. Отсюда мгновенные прикидки: миллиард записей (2^30) × 1 КБ (2^10) = 1 ТБ (2^40). Вся back-of-envelope-арифметика storage держится на этом одном правиле.
• 2^32 = 4 294 967 296 ≈ 4.3 млрд — предел 32-битного счётчика: «4 млрд записей — и 32-битный ID/offset кончился» (классический доп. вопрос: почему у Instagram/YouTube id 64-битные).
• 2^16 = 65 536 — 16-битный порт; 64 КБ — размер, который стоит помнить про UDP-датаграммы и максимальный TCP-window старых стеков.
• 2^40 = 1.1 × 10^12 ≈ 10^12 — «триллион строк» уже не влезает ни в одну ноду с индексами: шардирование/колоночные БД.

Мнемоника точных значений: 1 024 → 65 536 (1024 × 64) → 1 048 576 → «1.07 млрд» → «4.29 млрд» → «1.1 трлн». Между соседними «удобными» ступенями (10/16/20/30/32/40) точные значения восстанавливаются умножением: 2^16 = 2^10 × 2^6 = 1024 × 64; 2^20 = 1024²; 2^30 = 1024³; 2^40 = 1024⁴. Достаточно помнить 1024ⁿ + множители, а не цифры.

2. Latency numbers every programmer should know

Дословно из источника (включая ratio-примечания автора):

Единицы: 1 нс = 10⁻⁹ с; 1 мкс = 1 000 нс; 1 мс = 1 000 мкс. Наглядная версия («latency numbers visualized», где 1 нс растянут до 1 с) — в исходных gists: jboner/2841832, hellerbarde/2843375.

2.1 Ratio-цепочки — как источник предлагает запоминать

Автор не случайно даёт колонку примечаний: запоминаются отношения, а не абсолюты.

• CPU-локальность: L2 = 14× L1; RAM = 20× L2 = 200× L1. Каждый выход за кэш — кратная потеря.
• Случайный доступ: random 4 KB с SSD (150 мкс) стоит примерно как 1 МБ из RAM (250 мкс) — и в ~67× дешевле HDD-seek (10 мс). Поэтому «HDD — только sequential, random — на SSD/RAM».
• Транспорт: «сжать 1 КБ» и «передать 1 КБ по гигабиту» стоят одинаково (10 мкс) — сжатие перед отправкой почти всегда выгодно.
• Классическая четвёрка «1 МБ последовательно»: RAM 250 мкс → SSD 1 мс (4×) → 1 Gbps 10 мс (10×) → HDD 30 мс (30×). Мегабайт из памяти — 120× быстрее, чем с HDD.
• Два масштаба сети: RT внутри ДЦ 0.5 мс vs RT через океан 150 мс — разница 300×; HDD-seek = 20× RT ДЦ (диск дольше, чем сетевой хоп!).

3. Производные метрики («handy metrics» из источника)

Источник сводит таблицу к шести числам «на поток»:

Полезная связка (наша): 10 Gbps ≈ 1.25 GB/s ≈ скорость sequential-read SSD — сеть 10G сравнялась с диском; RAM (4 GB/s ≈ 32 Gbps) — уровень сетей 32–40G, «память быстрая, но сеть до неё ещё не дотянулась».

4. Мнемоники и тренажёр проговора

4.1 Лестница (учить одной фразой)

«Пол-нано — кэш, сто нано — память, десять микро — сеть/сжатие килобайта, полмилли — хоп в ДЦ, десять милли — HDD-seek и мегабайт по сети, тридцать милли — мегабайт с HDD, сто пятьдесят милли — океан».

Уровни: нс (CPU/RAM) → мкс (сеть/сжатие/SSD-random) → мс (RT ДЦ, SSD-мегабайт, HDD, мегабайт по сети) → сотни мс (океан). В каждой ступени — свои «дела», перепутать нельзя.

4.2 Человеческий масштаб (1 нс = 1 с)

Отсюда разговорная формулировка для доски: «в масштабе процессора поход в соседний дата-центр — это командировка на неделю, а через океан — на пять лет; поэтому кэш, батчинг и локальность».

4.3 Ratio-якоря (проговаривать парами)

1. RAM : SSD-random = 100 нс : 150 мкс = 1 : 1500 — «случайное чтение на SSD — это полторы тысячи походов в память».
2. RT-ДЦ : океан = 0.5 мс : 150 мс = 1 : 300 — «десять хопов в ДЦ дешевле одного океанского вызова на два порядка».
3. HDD-seek : RT-ДЦ = 1 : 20 — «seek медленнее сетевого хопа в 20 раз» (ломает интуицию — аудитория запоминает).
4. Мегабайт: RAM → SSD → 1Gbps → HDD = 0.25 мс → 1 мс → 10 мс → 30 мс — «каждый шаг вниз по пирамиде хранения ×4–30».

4.4 Тренажёр (5 минут в день, до слота 18.09)

1. Закрыть таблицы, написать от руки: степени двойки (6 строк), latency (15 строк), 6 производных метрик.
2. Проговорить вслух три ratio-якоря и лестницу из §4.1.
3. Решить на скорость (по 60 с, из KB §2): storage для 100 млн ссылок/мес; QPS для 100M DAU × 10 чтений; bandwidth для 100k просмотров × 110 МБ. Проверка по KB §2.2–2.4.
4. Критерий готовности: все 15 latency-строк + 6 метрик без запинки, три back-of-envelope за 60 с каждый.

5. Дополнительные вопросы из Appendix (меню тренировок)

Третья часть Appendix — 23 типовых дизайн-вопроса со ссылками на разборы. Переведены и разложены по подготовке. Приоритет: HR сказал «крупноблочная схема инстаграм/твиттер» → всё, что является подсистемой соцсети, тренеруем как мини-секции (15–20 мин на доске), остальное — общий кругозор.

5.1 Уже покрыты эталонами (classic-designs.md)

5.2 Подсистемы соцсетей — мини-секции для тренировки (приоритет)

Логика: rate limiter, trending/top-k, Snowflake-ID и timeline сами всплывают внутри инстаграм/твиттер на этапе «детали» — отработать их отдельно, чтобы на секции называть одним предложением.

5.3 Общий кругозор (читать разбор, не тренеровать доской)

5.4 Real world architectures (четвёртая часть Appendix)

Там же в Appendix — каталог «как это устроено в реальности» (MapReduce, Spark, Bigtable, Cassandra, Dynamo, Spanner, Kafka, GFS/HDFS, Chubby, Dapper + архитектуры компаний: Twitter, Facebook/Instagram, Netflix, WhatsApp, Pinterest…). Правило источника: не заучивать детали, а извлекать общие паттерны — какую проблему решает каждый компонент, где работает, где нет, чему авторы научились. Для нашей секции самые релевантные: Twitter timelines at scale (fan-out, лекция InfoQ), Instagram 14M users (аккуратнее: цифры 2011 года — используйте как иллюстрацию эволюции, не как факт), Scaling memcached at Facebook.

Полный каталог — в исходном README ниже раздела вопросов: README.md#real-world-architectures.

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

• ../knowledge-base.md §1–2 — сжатая экзаменационная версия этих таблиц + back-of-envelope-примеры
• ../methodology.md §5 — куда вставить тренажёр из §4 в план подготовки под слоты
• ../classic-designs.md — разборы по четырём вопросам из §5.1
• sdp-guide.md — конспект полного гайда (TASK-45.7, следующая часть источника)