---
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 (таблица степеней двойки)

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

| Power | Exact Value | Approx Value | Bytes |
|-------|-------------|--------------|-------|
| 2^7 | 128 | | |
| 2^8 | 256 | | |
| 2^10 | 1 024 | 1 thousand | 1 KB |
| 2^16 | 65 536 | | 64 KB |
| 2^20 | 1 048 576 | 1 million | 1 MB |
| 2^30 | 1 073 741 824 | 1 billion | 1 GB |
| 2^32 | 4 294 967 296 | | 4 GB |
| 2^40 | 1 099 511 627 776 | 1 trillion | 1 TB |

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

- **Ключевое приближение: 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-примечания автора):

| Действие | Время | Примечание из источника |
|----------|-------|--------------------------|
| L1 cache reference | 0.5 нс | |
| Branch mispredict | 5 нс | |
| L2 cache reference | 7 нс | 14× L1 |
| Mutex lock/unlock | 25 нс | |
| Main memory reference | 100 нс | 20× L2, 200× L1 |
| Compress 1 KB (Zippy/Snappy) | 10 мкс | |
| Send 1 KB over 1 Gbps network | 10 мкс | |
| Read 4 KB randomly from SSD | 150 мкс | ~1 GB/s SSD |
| Read 1 MB sequentially from memory | 250 мкс | |
| Round trip within same datacenter | 500 мкс | |
| Read 1 MB sequentially from SSD | 1 мс | ~1 GB/s SSD, 4× memory |
| HDD seek | 10 мс | 20× datacenter roundtrip |
| Read 1 MB sequentially from 1 Gbps | 10 мс | 40× memory, 10× SSD |
| Read 1 MB sequentially from HDD | 30 мс | 120× memory, 30× SSD |
| Send packet CA → Netherlands → CA | 150 мс | |

Единицы: 1 нс = 10⁻⁹ с; 1 мкс = 1 000 нс; 1 мс = 1 000 мкс. Наглядная версия («latency numbers visualized», где 1 нс растянут до 1 с) — в исходных gists: [jboner/2841832](https://gist.github.com/jboner/2841832), [hellerbarde/2843375](https://gist.github.com/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» из источника)

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

| Метрика | Значение | Практические следствия для back-of-envelope |
|---------|----------|----------------------------------------------|
| Sequential read HDD | **30 MB/s** | 1 ГБ ≈ 33 с; ~108 ГБ/час; 1 ТБ ≈ 9 ч. Значит: батч-джобы по терабайтам на HDD-кластере — это часы, не минуты |
| Sequential read 1 Gbps | **100 MB/s** | 1 ГБ = 10 с; 1 ТБ ≈ 3 ч. Проверка узких мест сети: 1 000 RPS × 100 КБ ответ = 100 МБ/с — гигабитный порт впритык |
| Sequential read SSD | **1 GB/s** | 1 ГБ = 1 с; 1 ТБ ≈ 17 мин. SSD-нода «ест» данные со скоростью сети 10G — диск больше не узкое место для sequential-нагрузок |
| Sequential read RAM | **4 GB/s** | 1 ГБ = 0.25 с; скан 100 ГБ целиком в памяти ≈ 25 с. Поэтому in-memory-кэш/движки меняют класс задачи |
| Round trips worldwide | **6–7/с** | RT через океан ≈ 150 мс. Один синхронный межконтинентальный вызов в горячем пути съедает треть бюджета p99 в 500 мс |
| Round trips in datacenter | **~2 000/с** | Хоп ≈ 0.5 мс. Цепочка из 5 последовательных сервисов = 2.5 мс только на сеть — говорим про depth запроса |

Полезная связка (наша): **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 с)

| Действие | «Человеческое» время | Запоминалка |
|----------|----------------------|-------------|
| L1 cache | 1 с | «моргнул — уже ответ» |
| RAM | ~2 мин | «сходил до холодильника» |
| SSD random 4 KB | ~2 суток | «выходные без интернета» |
| RT в ДЦ | ~6 суток | «неделя на согласование» |
| HDD seek | ~4 месяца | «один семестр» |
| 1 МБ с HDD | ~1 год | «диплом не напишешь» |
| RT через океан | ~5 лет | «одна поездка на другой континент — половина вуза» |

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

### 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`)

| Вопрос из Appendix | Наш разбор |
|--------------------|------------|
| Design a tinyurl system (Bitly) | §1 URL shortener — эталон Яндекса |
| Design the Facebook news feed | §2 Лента новостей (Instagram/Twitter) |
| Design a chat app (WhatsApp) / Facebook chat | §3 Мессенджер |
| Design a picture sharing system (Instagram, Picasa) | §4 Медиа-хостинг |

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

| Вопрос | Ключевая идея | Ссылка из источника |
|--------|---------------|---------------------|
| Design an API rate limiter | token/leaky bucket, Redis+Lua, 429+Retry-After | [stripe.com/blog/rate-limiters](https://stripe.com/blog/rate-limiters) |
| Design a trending topic system (Twitter) | sliding window + count-min sketch, поток через Kafka/Storm | [michael-noll.com](http://michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/) |
| Return the top k requests during a time interval | heap k-top, windowed counters | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf) |
| Design a random ID generation system | Snowflake: время+машинa+счётчик, сортируемые 64-бит ID | [blog.twitter.com (Snowflake)](https://blog.twitter.com/2010/announcing-snowflake) |
| Design the Facebook timeline | денормализация, pre-computed страницы | [facebook.com (note)](https://www.facebook.com/note.php?note_id=10150468255628920) |
| Design a key-value store (Redis/Dynamo) | consistent hashing, quorum W+R>N, hinted handoff | [Dynamo paper](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) |
| Design a cache system (Memcached) | cache-aside, консистентность, hot keys | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
| Design a CDN (CloudFlare) | edge-кэш, origin shield, инвалидация, geo-DNS | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |

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

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

| Вопрос | Ключевая идея | Ссылка из источника |
|--------|---------------|---------------------|
| Design a search engine (Google) | crawler → инвертированный индекс → ранжирование | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407) |
| Design a scalable web crawler | BFS frontier, politeness, dedup URL | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |
| Design a file sync service (Dropbox) | чанки, дедуп, sync-протокол, дельты | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |
| Design Google Docs | совместное редактирование, OT/CRDT | [neil.fraser.name/writing/sync](https://neil.fraser.name/writing/sync/) |
| Design a recommendation system (Amazon) | item-to-item collaborative filtering | [ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf) |
| Design a graph search (Facebook) | соцграф, index по типам рёбер | [facebook.com (note)](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph-search/10151347573598920) |
| Serves data from multiple data centers | geo-репликация, направление записи, консистентность | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
| Design an online multiplayer card game | async-состояние игры, вебсокеты | [buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
| Design a garbage collection system | mark-and-sweep на уровне идей | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/) |
| Design a stock exchange (NASDAQ/Binance) | order book, matching engine, латентность | [Jane Street (youtube)](https://youtu.be/b1e4t2k2KJY) |

### 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](https://github.com/donnemartin/system-design-primer/blob/master/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, следующая часть источника)