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): числа пронизывают секцию целиком. На этапе 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 §1; здесь — с мнемониками и тем, как это звучит на доске.

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

Ключевое приближение, на котором держится вся 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

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

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

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

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

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

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

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

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

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

Каждая ступень — свои «дела»: на наносекундах живёт 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 Производные метрики: таблица «на поток»

Плюс два «частотных» числа: 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 §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. От числа к решению: сигнальная таблица

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

Сигнальная таблица — мост между этой статьёй и остальными разделами: почти каждый «паттерн» из статей 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 §4), относящееся к оценкам:

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

Обязательные фразы и действия, по которым видно, что раздел освоен. Полный чек-лист всех этапов — карточка ../methodology.md §7; канон чисел — ../knowledge-base.md §1–2 (учить по нему, ../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 §6, тренажёр на 5 минут в день — ../materials/sdp-appendix-numbers.md §4.4, эталонные прогоны с числами — ../classic-designs.md §1–2. Если три свежие задачи подряд сходятся по таймингу и каждое число кончается выводом — раздел готов.

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

• 00-overview.md — обзорная статья по всем 12 разделам брифа (TASK-45.40)
• 01-interview-framework.md — соседняя статья: каркас, на этапе 5 которого живут эти расчёты
• ../brief.md — бриф: раздел 02 с критерием «умею, если»
• ../knowledge-base.md §1–2 — канон чисел и примеры: степени двойки, латентности, календарь, девятки, метод и гигиена оценок (учить по нему)
• ../methodology.md — §2 карточка этапа 5, §4 топ-10 ошибок, §6 протокол тренировок, §7 одностраничная карточка на секцию
• ../classic-designs.md — §1 URL shortener и §2 лента новостей: те же числа в полных разборах
• ../materials/sdp-appendix-numbers.md · ../materials/alex-xu-vol1/ch-02-back-of-envelope.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)