---
title: Статья 02 — Оценки: back-of-envelope, числа, латентность
source: подготовлено 2026-09-18, TASK-45.42; каркас — brief.md §02; развёртка knowledge-base.md §1–2; источники — SDP Appendix (TASK-45.6), Alex Xu гл. 2 (TASK-45.38), interactive latency (TASK-45.25), эталоны classic-designs.md §1–2
---

# Статья 02: оценки back-of-envelope, числа, латентность

Вторая статья серии — арифметика, на которой сходится любой дизайн. Критерий «умею, если» из брифа: **по любому сервису за 2 минуты называю RPS, объём хранения на 5 лет и ширину канала**. Это не про точность — это про способ доказать интервьюеру (и себе), что спроектированная схема соответствует заявленному масштабу, а не просто «красиво нарисована».

Место раздела в каркасе (статья [`01-interview-framework.md`](01-interview-framework.md)): числа пронизывают секцию целиком. На этапе 1 — числа-гипотезы в листе требований («10 млн DAU, чтение доминирует 100:1? — допущение, поправьте»). На этапе 4 — выбор компонента для детализации («горячий путь — чтение → глубоко копаю read-путь»). На этапе 5 — явные расчёты: 3–4 прикидки по формуле «допущение → формула → число → вывод» и горлышко раньше, чем его спросят. На этапе 6 — возврат к требованиям числом («SLO обеспечен с запасом — вот расчёт»). Оценка без схемы пуста, схема без оценки неверифицируема.

Контекст нашей секции (Yandex Codenv, этап 2): интервьюер из статьи Яндекса прямо требует «latency numbers вспомнить обязательно» — порядки латентностей это не факультатив, а проверяемый пункт. А «инстаграм/твиттер» из вводной — задачи, где все ключевые развилки (кэш, KV-зеркало, fan-out, CDN) выбираются именно числами, а не вкусом.

## 1. Зачем секции арифметика: три работы чисел

Back-of-envelope — «вычисления на салфетке» в формулировке Джеффа Дина (Google): оценки на основе мысленных экспериментов и типовых показателей производительности, которые дают представление о том, какие архитектуры соответствуют требованиям. На секции числа делают три работы:

**1. Превращают «funny money» в инженерные величины.** Массовые круглые числа из вводной («500 млн MAU») — не то, из чего проектируют; Gabbard зовёт их funny money. Цепочка конверсии — 500 млн MAU × 70 % → 350 млн DAU → × 70 % в час пика → ÷ 3 600 → ~68 тыс. одновременных → ÷ 1 000 запросов с ноды → ~68 нод — превращает невообразимое в трактабельное: из «миллиардов пользователей» получается «семьдесят серверов».

**2. Доказывают, что дизайн сходится.** Схема из коробок — гипотеза; расчёт — её проверка. «Кэш справится с read QPS» — пустой звук; «35 тыс. QPS пика ÷ 100 тыс. RPS на KV-ноду = меньше одной ноды, значит кэш не горлышко» — аргумент. Интервьюер оценивает именно связку: нарисовал → посчитал → подтвердил или переделал.

**3. Находят горлышко раньше вопроса.** Классика: интервьюер спрашивает «а что здесь узкое место?» — и кандидат задумывается впервые. Сильный ход — наоборот: расчёт сам называет дефицитный ресурс («storage — 12 ТБ, не проблема; вот чтение 500 тыс. RPS — узкое место, поэтому KV-зеркало и кэш»). Это разница между «знает паттерны» и «проектирует».

Что при этом оценивается (по статье Яндекса): умение считать нагрузку входит в явный список критериев. Формат ответа — всегда вслух: **допущение → формула → число → вывод**. Число без формулы не оценивается: интервьюер не может отличить прикидку от угаданного ответа.

## 2. Инструментарий в кармане: степени двойки, размеры, календарь, девятки

Всё, что нужно держать в голове до автоматизма. Экзаменационная версия — [`../knowledge-base.md`](../knowledge-base.md) §1; здесь — с мнемониками и тем, как это звучит на доске.

### 2.1 Степени двойки: одно правило на всё

| Степень | Приближение | Название |
|---------|-------------|----------|
| 2^10 | ~1 тысяча | 1 KiB |
| 2^20 | ~1 миллион | 1 MiB |
| 2^30 | ~1 миллиард | 1 GiB |
| 2^40 | ~1 триллион | 1 TiB |
| 2^50 | ~1 квадриллион | 1 PiB |
| 2^60 | ~1 квинтиллион | 1 EiB |

Ключевое приближение, на котором держится вся storage-арифметика: **2^10 ≈ 10^3** (1 024 ≈ тысяча). Отсюда мгновенные прикидки: миллиард записей × 1 КиБ = 1 ТиБ (2^30 × 2^10 = 2^40); миллион × 100 байт ≈ 100 МиБ; триллион × 1 КиБ = 1 ПиБ. Точные значения восстанавливаются умножением: 2^20 = 1024², 2^30 = 1024³ — достаточно помнить «1024ⁿ + множители», а не цифры.

Две степени сверх таблицы, которые спрашивают отдельно: **2^32 ≈ 4.3 млрд** — предел 32-битного счётчика («4 млрд записей — и int-овый ID/offset кончился», классический доп. вопрос: почему у Instagram/YouTube идентификаторы 64-битные) и **2^16 = 65 536** — 16-битный порт.

### 2.2 Размеры типовых сущностей: из чего складывается storage

| Сущность | Размер |
|----------|--------|
| Символ ASCII / байт UTF-8 (латиница) | 1 байт |
| Int / float | 4 байта |
| Long / double / Unix-timestamp (int64) | 8 байт |
| IPv4 / IPv6 / UUID | 4 / 16 / 16 байт |
| SHA-256 (хеш) | 32 байта |
| Короткая строка / URL | ~50–500 байт |
| Запись в БД среднего размера | ~100 байт – 1 КиБ |
| Страница HTML (сжатая) | ~50–100 КиБ |
| Фото (сжатое) | ~0.1–5 МиБ |
| Минута видео 480p / 1080p | ~10 МиБ / ~50–100 МиБ |

Называя размер записи, сразу проговариваем состав: «твит = id 8 байт + текст ~140 байт + медиа ~1 МиБ» — интервьюер видит, что оценка собрана, а не взята с потолка. И типовая поправка, которую забывают новички: **сырые данные ≠ место на диске** — индексы и оверхед добавляют ×2 (хорошая прикидка), репликация ×2–3 сверху.

### 2.3 Календарные константы: знаменатели всех формул

| Константа | Значение | Округление для доски |
|-----------|----------|----------------------|
| 1 час | 3 600 с | 3.6 × 10^3 |
| 1 сутки | 86 400 с | ~100 тыс. с (10^5) |
| 1 месяц (30 дней) | 2 592 000 с | ~2.5 млн с |
| 1 год | 31 536 000 с | ~30 млн с (3 × 10^7) |

Сутки ≈ 10^5 секунд и год ≈ 3 × 10^7 секунд — два числа, через которые считается любой QPS (`DAU × действия / 86 400`) и любой storage за горизонт (`записей/с × 3 × 10^7 × лет`). Полезная опора «на глаз»: **«1 КиБ-запись на скорости 1/с — это ~30 ГиБ в год»**; чтобы накопить терабайты за год — нужна либо ~40 записей/с, либо записи в МиБ (медиа).

### 2.4 Доступность: девятки в минутах простоя

| SLA | Простой в год |
|-----|---------------|
| 99 % | 3.65 дня |
| 99.9 % («три девятки») | 8.7 часа |
| 99.99 % («четыре девятки») | 52 минуты |
| 99.999 % («пять девяток») | 5 минут |

Формула: `простой = (100 − SLA)% × год`. Это тоже оценка — и её результат управляет архитектурой: три девятки терпят плановый рестарт одной ноды, четыре — требуют N+1 на каждом ярусе, пять — уже не про количество нод, а про много-ДЦ, отказ домена и автоматический failover (разделы 08–09 брифа). Проговаривать девятки именно в минутах/часах простоя: «четыре девятки — это 52 минуты в год, один неудачный деплой их съедает».

## 3. Латентности: лестница, отношения, тренды

Вторая половина раздела — порядки времени, за которое происходят базовые операции. Канон — таблица Jeff Dean / System Design Primer; наша экзаменационная версия в KB §1.2. Учить надо не «таблицу на 15 строк», а лестницу и отношения.

### 3.1 Лестница: одна фраза на всё

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

| Уровень | Порядок | Обитатели |
|---------|---------|-----------|
| наносекунды | 0.5–100 нс | L1 0.5 нс, branch mispredict 5 нс, L2 7 нс, mutex 25 нс, RAM 100 нс |
| микросекунды | 3–250 мкс | сжатие 1 КиБ ~3–10 мкс, 2 КиБ по 1 Gbps 20 мкс, random 4 КиБ с SSD ~150 мкс, 1 МиБ из RAM 250 мкс |
| миллисекунды | 0.5–30 мс | RT в ДЦ 0.5 мс, 1 МиБ с SSD ~1 мс, HDD seek 10 мс, 1 МиБ по 1 Gbps 10 мс, 1 МиБ с HDD 30 мс |
| сотни мс | ~150 мс | round-trip через океан |

Каждая ступень — свои «дела»: на наносекундах живёт CPU и кэши, на микросекундах — SSD и сеть внутри стойки, на миллисекундах — сетевые хопы и диски, на сотнях миллисекунд — планета. Перепутать класс нельзя: мьютекс не бывает «микросекундным», RT в ДЦ не бывает «наносекундным».

Человеческий масштаб для запоминания (1 нс = 1 с): RAM — «до холодильника» (~2 мин), random read SSD — «выходные» (~2 суток), RT в ДЦ — «неделя согласований» (~6 суток), HDD seek — «семестр» (~4 месяца), океан — «пять лет». Разговорная формулировка для доски: «в масштабе процессора поход в соседний ДЦ — командировка на неделю, через океан — на пять лет; поэтому кэш, батчинг и локальность».

### 3.2 Ratio-якоря: запоминаются отношения, а не абсолюты

Три пары, которых хватает, чтобы восстановить всю таблицу и блеснуть на секции:

1. **RAM : SSD-random = 100 нс : 150 мкс ≈ 1 : 1500** — «случайное чтение на SSD — полторы тысячи походов в память». Следствие: random reads на HDD (×67 хуже SSD) — запрещённый приём, только SSD/RAM.
2. **RT-ДЦ : океан = 0.5 мс : 150 мс = 1 : 300** — «триста хопов внутри ДЦ дешевле одного океанского вызова». Следствие: синхронный вызов через океан в горячем пути — треть бюджета p99 в 500 мс; гео-шардирование или асинхронность.
3. **HDD-seek : RT-ДЦ = 10 мс : 0.5 мс = 1 : 20** — «seek медленнее сетевого хопа в 20 раз» (ломает интуицию — потому и запоминается).

Классическая четвёрка «1 МиБ последовательно»: RAM 250 мкс → SSD ~1 мс (×4) → 1 Gbps 10 мс (×10) → HDD 30 мс (×30). И симметричная пара: «сжать 1 КиБ» и «передать 1 КиБ по гигабиту» стоят **одинаково (~10 мкс)** — сжатие перед отправкой почти всегда выгодно.

### 3.3 Производные метрики: таблица «на поток»

| Канал | Скорость последовательного чтения | Следствие |
|-------|-----------------------------------|-----------|
| RAM | ~4 ГиБ/с | скан 100 ГиБ в памяти ≈ 25 с — in-memory-движок меняет класс задачи |
| SSD | ~1 ГиБ/с (NVMe до 3–7) | SSD-нода «ест» данные со скоростью сети 10G — для sequential диск не горлышко |
| HDD | ~30–100 МиБ/с | терабайты на HDD — часы: батч-джобы планируем заранее |
| Сеть 1 Gbps | ~100–125 МиБ/с | 1 000 RPS × 100 КиБ ответ = 100 МиБ/с — гигабитный порт впритык |
| Сеть 10 Gbps | ~1 ГиБ/с | сравнялась с sequential-SSD |

Плюс два «частотных» числа: RT внутри ДЦ — это ~2 000 round-trip'ов в секунду (цепочка из 5 последовательных сервисов = 2.5 мс только на сеть — глубина запроса стоит денег), свет вокруг Земли — 5–7 оборотов/с (до другого континента — ~150 мс, и это не лечится).

### 3.4 Тренды: откуда числа и почему не изменятся

Глубина, отличающая «выучил таблицу» от «понимаю масштаб» (материал 21, colin-scott):

- **«Полоса дешевеет, латентность — нет».** Полосы удваиваются каждые 2–3 года; полы латентности не сдвинулись за 20+ лет: RAM 100 нс (шина даже деградирует), RT в ДЦ 0.5 мс, океан 150 мс — скорость света. Отсюда все паттерны throughput-first: **батчить, пайплайнить, параллелить, меньше round-trip'ов** — одной фразой объясняет батчи в Kafka и мультиплексирование HTTP/2.
- **Стена частот — 2005.** Герцы замерли на ~3 ГГц; растут ядра, не герцы. Ответ на «почему нельзя подождать более быстрое железо»: горизонтальное масштабирование — не выбор, а следствие физики.
- **Порог восприятия ~100 мс:** лаг меньше человек не замечает. Отсюда SLO 150 мс у эталона Яндекса — «на грани комфорта», а round-trip через океан (~150 мс) съедает весь бюджет ответа.
- На секции безопаснее консервативные значения канона — «называю порядок, не десятые доли»: CPU-числа плавают в разы от машины к машине.

## 4. Метод: шесть вопросов и правило подачи

Back-of-envelope на секции — не свободная импровизация, а прогон по фиксированному списку вопросов себе (KB §2.1). Порядок важен: каждый следующий шаг считается от предыдущего.

1. **Масштаб пользователей:** DAU/MAU, одновременные в пике. (MAU × доля активных в сутки → DAU; DAU × доля в час пика ÷ 3 600 → одновременные.)
2. **RPS:** `QPS_avg = DAU × действий/сутки ÷ 86 400`; `QPS_peak ≈ 2–3 × avg` (утро/вечер, релизы, вирусный контент). Чтение обычно ≥ записи в 10–100 раз; но запись — узкое место по консистентности.
3. **Storage:** `записей/с × размер × 3 × 10^7 × лет удержания × фактор репликации`, плюс индексы (×2 от сырых данных — хорошая прикидка).
4. **Bandwidth:** `чтение = read QPS × размер ответа`, `запись = write QPS × размер объекта`. Сравнить с 1/10 Gbps на ноду и решить: нужен ли CDN, сжатие, шардирование канала.
5. **Память кэша:** правило 80/20 — 20 % объектов дают 80 % трафика; `кэш = 0.2 × (объём горячего набора)` — например `0.2 × DAU × действий/сутки × размер объекта`.
6. **Серверы:** типовой сервис-нода держит ~1–10 тыс. RPS (зависит от CPU-bound vs IO-bound); `ноды = QPS_peak ÷ RPS_ноды × запас N+1`. БД — сразу делить роли (write-мастер, read-реплики), не «одна нода потянет».

Правило подачи — проговаривать каждый шаг как **«допущение → формула → число → вывод»**: «*Допущение:* 100 млн DAU, 10 открытий ленты в сутки. *Формула:* 100 млн × 10 ÷ 86 400. *Число:* ~11.5 тыс. QPS среднее, пик ×3 → ~35 тыс. *Вывод:* это единицы-десятки сервисных нод — не экстремально; узкое место ищем дальше, в fan-out». Четыре звена, секунд двадцать речи — и оценка засчитана.

## 5. Сквозной пример 1: URL shortener (полный прогон)

Эталонная задача Яндекса (полный разбор — [`../classic-designs.md`](../classic-designs.md) §1). Показываем, как из вводной за пару минут получается весь каркас ресурсов. Числа вводной: 500 тыс. RPS чтения в пике, 1 млрд ссылок всего, 100 млн новых в месяц, 150 мс p95 на чтение, retention 10 лет.

**Шаг 1–2, масштаб и RPS.** Чтение задано: 500 тыс. RPS в пике (это и есть data plane). Запись: 100 млн новых/мес ≈ 3.3 млн/сутки ÷ 86 400 ≈ **~40 RPS записи** (в эталоне — «сотни тысяч в день, 10–20 RPS», тот же порядок). Соотношение read/write ~12 000:1 — сервис на четыре порядка про чтение. *Вывод: дизайн крутится вокруг read-пути; записи почти не считаем.*

**Шаг 3, storage.** 100 млн/мес × 12 × 10 лет = 12 млрд записей × ~500 байт ≈ 6 ТБ сырых; с индексами и оверхедом ×2 → **~12 ТБ** (текущая база в эталоне — ~1 млрд записей × сотни байт = сотни ГБ; на горизонте 10 лет она вырастает до 12 млрд). *Вывод: терабайты — одна-две ноды с дисками; storage не узкое место.*

**Шаг 4, bandwidth.** Чтение: 500 тыс. RPS × ~200 байт ответа (redirect-заголовок) ≈ 100 МиБ/с ≈ 1 Gbps суммарно на входящие вэб-ноды — несколько нод с гигабитными портами, без CDN. *Вывод: канал не горлышко, провайдер CDN не нужен — это не медиа.*

**Шаг 5, кэш/KV-зеркало.** Реляционная СУБД 500 тыс. RPS чтения не отдаст → KV-зеркало: ~100 ГБ (миллиард × ~100 байт пары), ~100 тыс. RPS на сервер. *Вывод из размера и нагрузки: данные не шардировать, а реплицировать — 100 ГБ в память одной-двух нод, реплики дают и чтение, и отказоустойчивость.*

**Шаг 6, ноды и дефицитный ресурс.** Вот где оценивается тонкость эталона: web-слой CPU-bound из-за TLS — каждый переход по короткой ссылке приходит новым TLS-handshake → **~20 тыс. RPS на сервер**, а не 100 тыс. `500 тыс. ÷ 20 тыс. = 25 воркеров` в пике, ×4 ДЦ и запас сценариев — получается план ёмкости. **Бюджет латентности** — оценка по таблице §3: клиент↔сервер до 120 мс (гео), воркер ≤ 10 мс (KV на localhost — единицы мс, маршрутизация в ДЦ — сотни мкс), итого ~130 мс < 150 мс p95. *Вывод: в бюджете лежим с запасом; сверх 4 ДЦ не распыляемся — запас сам отменяет гео-расширение.*

Обратите внимание на форму: каждый расчёт кончается выводом, и выводы складываются в архитектуру («не шардируем, реплицируем», «25 воркеров», «без CDN»). Это и есть «дизайн сходится арифметически».

## 6. Сквозной пример 2: лента новостей (fan-out меняет вывод)

Вводная (KB §2.3, полный разбор — classic-designs §2): 100 млн DAU, 10 открытий ленты в сутки, 2 поста в сутки, в среднем 300 подписчиков.

**RPS.** Чтение: `100 млн × 10 ÷ 86 400 ≈ 11.5 тыс. QPS avg`, пик ×3 → **~35 тыс. QPS**. Запись постов: `100 млн × 2 ÷ 86 400 ≈ 2.3 тыс. QPS`. Сами по себе числа умеренные: чтение — единицы-десятки сервисных нод. *Промежуточный вывод: по голому QPS система «обычная».*

**Fan-out — главный расчёт задачи.** Каждый пост должен попасть в ленту каждому подписчику: `2.3 тыс. постов/с × 300 подписчиков ≈ 700 тыс. вставок/с`. Это на два порядка больше записи и в 20 раз больше пикового чтения. *Вывод: узкое место — не пост, а доставка; отсюда центральная развилка дизайна — fan-out on write (заранее готовим ленты, дорого для селебрити) vs on read (собираем при открытии, дорого при чтении) и микс для аккаунтов-миллионников.*

**Кэш горячих лент (80/20).** Считаем от объёма: 10 открытий × ~10 постов × ~100 байт ≈ 10 КиБ суточной ленты на пользователя; × 100 млн DAU ≈ 1 ТиБ суточных лент; горячие 20 % по правилу 80/20 → **~200 ГиБ в памяти** — единицы-десятки нод in-memory. *Вывод: лента — pre-computed данные в кэше, пост — событие в очереди, сборка — асинхронный воркер* (раздел 07 брифа).

Смысл примера: два сервиса с «похожими» QPS имеют разные горлышки, и это выясняется только расчётом. У URL shortener узкое место — TLS на чтении; у ленты — fan-out доставки. Ошибка в таком выводе не прощается — она означает проектирование не того компонента.

## 7. Короткий пример 3: bandwidth видео-хостинга

Третий типовой сюжет — когда канал становится главным числом (KB §2.4). Дано: 10 тыс. загрузок/сутки × ~1 ГБ исходник; 100 тыс. просмотров/сутки по 5 мин при 3 Mbps ≈ 110 МиБ.

- **Storage-рост:** 10 тыс. × 1 ГБ = 10 ТБ/сутки исходников, транскоды ×3–5 версий → **30–50 ТБ/сутки**; за год — десятки ПБ → только объектное хранилище (S3-класс).
- **Egress:** 100 тыс. × 110 МиБ ≈ 10 ТБ/сутки → `10 ТБ ÷ 86 400 с ≈ 120 МиБ/с ≈ 1 Gbps` средний поток, пик ×3–5 → **3–5 Gbps**. *Вывод: отдавать клиентам напрямую из кластера нельзя (дорого и медленно глобально) → CDN с offload 90 %+.*
- **Транскодинг:** минуты CPU на минуту видео × 10 тыс. видео/сутки → асинхронный пайплайн через очередь; отставание обработки от загрузки на минуты — приемлемо и проговаривается как осознанный трейдофф.

Шаблон узнаваем: как только в ответе «видео/фото» — первой оценкой должен быть egress, а не QPS.

## 8. От числа к решению: сигнальная таблица

Оценка ничего не стоит без вывода. Сводка типовых сигналов и архитектурных ходов, к которым они ведут:

| Сигнал из расчёта | Вывод | Куда в дизайне (раздел брифа) |
|-------------------|-------|-------------------------------|
| Read/write ≥ 100:1 | «дизайн про чтение» | кэш + read-реплики; путь записи упрощаем (06, 05) |
| Storage ≤ единицы ТБ при ТиБ-записях | storage не горлышко | фокус на RPS; репликация вместо шардирования |
| Storage ≥ десятки ТБ и рост | не одна нода | шардирование по ключу, объектное хранилище для медиа (04, 05) |
| Fan-out × подписчики ≫ записи | узкое место доставка | очередь + pre-computed ленты, микс для селебрити (07, 11) |
| Egress ≥ Gbps | канал дорог | CDN, сжатие, адаптивные битрейты (03, 06) |
| QPS_ноды впритык, CPU-bound (TLS!) | считать от дефицитного ресурса | LB + горизонтально, ко-локация компонентов (03) |
| p99-бюджет ≈ RT океана | гео решает | гео-DNS/шардирование, асинхронные межрегиональные пути (08) |
| Четыре девятки и выше | рестарт ноды ≠ простой | N+1 каждый ярус, много-ДЦ, majority-коммит (08, 09) |

Сигнальная таблица — мост между этой статьёй и остальными разделами: почти каждый «паттерн» из статей 03–11 на секции обосновывается строкой отсюда.

## 9. Гигиена оценок: как подавать прикидку

Правила из Alex Xu (гл. 2, KB §2.5) — про форму, из-за которой оценку засчитывают или нет:

- **Округлять.** Не «11.64 МБ», а «примерно 10 МБ»: интервью про порядок, не про точность. Сложную арифметику упрощать: 99 987 ÷ 9.1 → 100 000 ÷ 10. Ошибка в 2 раза — не провал (мало серверов — докупим); ошибка на порядок — уже да.
- **Записывать допущения.** «Предположим 100 млн DAU и 2 поста в сутки» — письменно в угол доски, к допущениям возвращаемся. Тогда интервьюер может *поправить вводную*, а не *оспорить результат*.
- **Подписывать единицы.** KB — килобайты, Kb — килобиты (×8 разницы); латентность в мс, bandwidth в МиБ/с. Неподписанное «5» — неоцениваемо.
- **Проверять размерность формулы.** `записей/с × байт × секунд = байты` — единицы сокращаются, как в физике; кто проверяет размерность, тот не теряет порядки.
- **Число без вывода не произносим.** Формула «допущение → формула → число → вывод» — все четыре звена, иначе расчёт повисает в воздухе.

Эталон подачи из книги (Twitter): 150 млн DAU × 2 твита ≈ 3.5 тыс. QPS записи, пик ×2 ≈ 7 тыс.; медиа ~30 ТБ/день; 5 лет ≈ 55 ПБ — «порядок величин важнее цифр».

## 10. Ошибки этого раздела

Подмножество топ-10 ошибок ([`../methodology.md`](../methodology.md) §4), относящееся к оценкам:

| Ошибка | Как выглядит | Противоядие |
|--------|--------------|-------------|
| Считать молча | Тишина 40 секунд, потом «12 ТБ» | Всё вслух: допущение → формула → число → вывод |
| Число без допущения | «Будет 500 ГБ» — «откуда?» | Каждое число от «допущение: …, поправьте» |
| Ложная точность | «11.64 МБ», «2 347.3 QPS» | Округлять до порядка; порядок и есть ответ |
| Путать KB и Kb | ×8 в bandwidth — ошибка на порядок | Подписывать единицы всегда |
| Забыть пик | Спроектировали на среднее, продакшн лёг в вечерний максимум | QPS_peak = 2–3 × avg по умолчанию |
| Забыть индексы и реплики | «6 ТБ» без ×2 индексов и ×3 репликации | Storage = сырые × 2 × репликация — проговаривать множители |
| Считать не тот ресурс | Ноды под QPS, а удушил TLS/CPU | Дефицитный ресурс называть явно (CPU/память/диск/канал) |
| Число ради числа | Ряд расчётов без выводов | Каждый расчёт кончается «→ поэтому …» |
| Девичья память чисел | «RAM вроде 10 мкс?» | Лестница §3.1 + три ratio-якоря до автоматизма |

## 11. Что назвать на секции (чек-лист раздела)

Обязательные фразы и действия, по которым видно, что раздел освоен. Полный чек-лист всех этапов — карточка [`../methodology.md`](../methodology.md) §7; канон чисел — [`../knowledge-base.md`](../knowledge-base.md) §1–2 (учить по нему, [`../materials/sdp-appendix-numbers.md`](../materials/sdp-appendix-numbers.md) — для сверки и контекста).

**На этапе требований (каждое — с «допущение, поправьте»):**
- DAU и действия/сутки на пользователя — вслух, в угол доски.
- «Чтение доминирует — read/write 100:1?» — соотношение фиксируем, от него пойдёт дизайн.
- Latency-SLO p95/p99 и девятки доступности — «на что именно».
- Retention: «сколько храним и что удаляем» — горизонт для storage.

**На этапе ресурсов (минимум 3 расчёта за секцию, ≥ 2 из них — с явной гипотезой):**
- RPS: среднее и пик — «пик ×2–3 к среднему: утро/вечер, релизы».
- Storage на горизонте: «записей × размер × retention × репликация, с индексами ×2 → …ТБ, это N нод».
- Bandwidth: «read QPS × размер ответа → …МиБ/с против гигабитного порта».
- Кэш по 80/20: «горячие 20 % → столько-то памяти — ленты влезают/не лезут».
- Ноды от дефицитного ресурса: «CPU-bound из-за TLS → 20 тыс. RPS на сервер → 25 нод ×4 ДЦ».
- Каждый расчёт — формула из четырёх звеньев, число — с единицами, конец — «поэтому …».

**Из латентностей (по требованию «назовите порядки»):**
- Лестница одной фразой: «пол-нано кэш, сто нано память, пол-милли хоп в ДЦ, десять милли HDD, сто пятьдесят милли океан».
- Ratio-якоря: RAM:SSD ≈ 1:1500, ДЦ:океан = 1:300, seek:хоп = 20:1.
- «Полоса дешевеет, латентность — нет» → батчить, пайплайнить, меньше round-trip'ов.
- Порог восприятия ~100 мс — почему SLO 150 мс «на грани», а океанский RT его съедает целиком.

**В финале (возврат к требованиям):**
- «SLO по латентности: бюджет …, фактическая цепочка …, запас …» — закрытие требования числом.

## 12. Самопроверка «умею, если»

Критерий раздела из брифа: **по любому сервису за 2 минуты называю RPS, объём хранения на 5 лет и ширину канала**. Проверяется прогоном, не чтением: закрыть материалы, взять произвольный сервис (доставка кофе, электронная библиотека, парковки) и вслух за 2 минуты прогнать шесть вопросов §4 — от DAU-гипотезы до нод и дефицитного ресурса. Затем — сверка: числа из §5–7 должны воспроизводиться от руки (12 ТБ shortener, 700 тыс. вставок/с fan-out, 3–5 Gbps видео), лестница латентностей — без запинки, девятки — в минутах простоя. Протокол тренировок и рубрика 0–3 — [`../methodology.md`](../methodology.md) §6, тренажёр на 5 минут в день — [`../materials/sdp-appendix-numbers.md`](../materials/sdp-appendix-numbers.md) §4.4, эталонные прогоны с числами — [`../classic-designs.md`](../classic-designs.md) §1–2. Если три свежие задачи подряд сходятся по таймингу и каждое число кончается выводом — раздел готов.

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

- [`00-overview.md`](00-overview.md) — обзорная статья по всем 12 разделам брифа (TASK-45.40)
- [`01-interview-framework.md`](01-interview-framework.md) — соседняя статья: каркас, на этапе 5 которого живут эти расчёты
- [`../brief.md`](../brief.md) — бриф: раздел 02 с критерием «умею, если»
- [`../knowledge-base.md`](../knowledge-base.md) §1–2 — канон чисел и примеры: степени двойки, латентности, календарь, девятки, метод и гигиена оценок (учить по нему)
- [`../methodology.md`](../methodology.md) — §2 карточка этапа 5, §4 топ-10 ошибок, §6 протокол тренировок, §7 одностраничная карточка на секцию
- [`../classic-designs.md`](../classic-designs.md) — §1 URL shortener и §2 лента новостей: те же числа в полных разборах
- [`../materials/sdp-appendix-numbers.md`](../materials/sdp-appendix-numbers.md) · [`../materials/alex-xu-vol1/ch-02-back-of-envelope.md`](../materials/alex-xu-vol1/ch-02-back-of-envelope.md) · [`../materials/lsd-interactive-latency.md`](../materials/lsd-interactive-latency.md) — источники чисел: канон SDP · глава Сюя с гигиеной и Twitter-примером · происхождение чисел и тренды железа
- Соседние статьи: `03-scaling.md` (куда ведут сигналы «QPS растёт», «egress ≥ Gbps») · `06-caching.md` (80/20 и горячий набор) · `08-fault-tolerance.md` (девятки и N+1)