Архитектура, придуманная до оценки порядков величин, слишком часто оказывается красивой, но нерелевантной реальному масштабу задачи.
Глава показывает, как back-of-the-envelope estimates помогают быстро увидеть, что насыщается первым - traffic, memory, disk, network или latency budget, и тем самым сэкономить время на раннем отборе решений и грубой capacity-модели.
Для system design interview это один из самых сильных сигналов зрелости: сначала назвать осмысленные допущения и главный constraint, а уже потом предлагать архитектуру, которая действительно отвечает на обнаруженный масштаб.
Практическая польза главы
Оценка за минуты
Быстро переводите продуктовый сценарий в числа: RPS/QPS, размер сообщения (payload), коэффициент пика (peak factor) и порядок инфраструктурных ограничений.
Главное узкое место (bottleneck)
Через оценки памяти, хранилища и сети (RAM/storage/network), а также бюджета задержки (latency budget), определяйте, какой слой упрется первым и где нужен архитектурный запас.
Формулировка решения (decision framing)
Сопоставляйте оценку с выбором паттернов: кэш, репликация, шардинг, асинхронная обработка (async processing) и ограничения SLA/SLO.
Подача на интервью (interview execution)
На интервью показывайте уверенную структуру: допущения, формулы, оценка рисков и аргумент следующего эволюционного шага.
Источник мышления
Designing Data-Intensive Applications
Хорошая опора для обсуждения пропускной способности (throughput), хранилища (storage) и компромиссов по задержке (latency trade-offs).
Примерные оценки (Back-of-Envelope Estimation) — это инструмент первых 5 минут архитектурного разбора. Он не дает точных оценок емкости (capacity), но быстро показывает порядок величин, ограничители системы и зону максимального риска.
Цель: до выбора технологий понять, где именно система упрется первой — в RPS, рабочий набор в памяти (RAM working set), рост диска (disk growth), пропускную способность сети (network throughput) или бюджет задержки (latency budget) критичного пользовательского сценария (user journey).
Быстрые константы и единицы
Время
- 1 день = 86 400 с (seconds)
- 1 месяц ≈ 30 дней
- Пик (peak) часто в 2-5 раз выше среднего
Трафик
- RPS = запросы/день (requests/day) / 86 400
- RPS_peak = RPS_avg * коэффициент пика (peak factor)
- Разделяйте чтения и записи (read/write)
Байты
- 1 KB = 10^3 B (приблизительно)
- 1 MB = 10^6 B
- 1 GB = 10^9 B
Пропускная способность
- Байт/с (bytes/sec) = RPS * размер сообщения (payload)
- Бит/с (bits/sec) = байт/с * 8
- Учитывайте накладные расходы протокола (protocol overhead)
Память
- RAM = горячий рабочий набор (hot working set)
- Плюс накладные расходы соединений и сессий (connection/session overhead)
- Оставляйте резерв 20-30% (headroom)
Хранилище
- Хранилище/день (storage/day) = записи/день (writes/day) * размер строки (row size)
- Учитывайте индексы и метаданные (index + metadata)
- Умножайте на фактор репликации (replication factor)
Шаблон оценки за 5 шагов
Шаг 1
Зафиксируйте входные допущения
Количество пользователей, ключевые пользовательские сценарии (user journeys), соотношение чтений и записей (read/write ratio), размер запроса/ответа, целевые SLA/SLO.
Шаг 2
Переведите бизнес-метрики в нагрузку
Посчитайте средний и пиковый RPS/QPS (average/peak), добавьте коэффициент всплеска (burst factor) и отдельно выделите критический путь записи (write path).
Шаг 3
Оцените ресурсы по слоям
Оцените оперативную память (RAM) для горячих данных (hot data) и кэша, постоянное хранилище (persistent storage) на горизонт планирования, пропускную способность сети (network throughput) между сервисами и наружу.
Шаг 4
Разложите бюджет задержки (latency budget)
Распределите бюджет p95/p99 по пограничному слою (edge), прикладному сервису (API), кэшу (cache), базе данных (DB) и внешним зависимостям. Сразу обозначьте самый дорогой сегмент.
Шаг 5
Найдите главное узкое место (bottleneck)
Определите, что ломается первым при росте в 5-10 раз (5-10x): процессор (CPU), память (memory), сеть (network), дисковые операции (storage IOPS), задержка координации (coordination latency) или операционная сложность (operational complexity).
Трафик (traffic) -> RPS/QPS: базовые формулы
Средняя и пиковая нагрузка (average/peak)
requests/day = DAU * requests_per_user/day
RPS_avg = requests/day / 86 400
RPS_peak = RPS_avg * peak_factor
Разделение чтений и записей (read/write split)
RPS_read = RPS_total * read_ratio
RPS_write = RPS_total * write_ratio
путь записи (write path) обычно задает требования к хранилищу (storage) и стоимости долговечности (durability cost)
Оперативная и постоянная память (RAM / persistent storage)
Оперативная память (RAM, working set)
Начинайте с горячих данных (hot data), которые нужны для достижения целевой задержки (target latency). Добавьте метаданные кэша (cache metadata), накладные расходы соединений и сессий (connection/session overhead) и минимум 20-30% запаса (headroom).
Горизонт постоянного хранилища (persistent storage horizon)
storage/day = writes/day * average_row_size
total/day = storage/day * replication_factor * (1 + index_overhead)
storage/N months = total/day * 30 * N
Пропускная способность сети и исходящий трафик (network throughput / egress)
Для каждого межсервисного перехода (hop) посчитайте: bytes/sec = RPS * payload. Затем переведите в бит/с (bits/sec) и добавьте накладные расходы (overhead): headers, TLS, retries, fan-out. Это сразу показывает, где потребуется сжатие, пакетирование (batching) или изменение контракта API.
Разложение бюджета задержки (latency budget decomposition)
Если сумма бюджета (budget) уже близка к целевому SLO, именно хвостовая задержка (tail latency) и политика повторов (retry policy) станут главным риском, даже если средние метрики выглядят нормально.
4 мини-кейса с быстрыми выводами
Кейс 1: Сокращатель ссылок (URL Shortener)
- 100M переадресаций/день (redirect/day)
- размер ответа (payload) = 1.2KB
- коэффициент пика (peak factor) = 3x
Расчет: RPS_avg ≈ 1 160, RPS_peak ≈ 3 500. Пиковый исходящий трафик (egress_peak) ≈ 3 500 * 1.2KB ≈ 4.2MB/s (~34Mbps) без учета накладных расходов TLS/headers.
Главная сложность: Критичная сложность обычно не в хранилище (storage), а в усилении чтений (read amplification), доле попаданий кэша (cache hit ratio) и p99 задержке (latency) на пути чтения (lookup path).
Кейс 2: Рассылка уведомлений (Notification fan-out)
- 5M событий/день (events/day)
- средний коэффициент рассылки (fan-out) = 8
- размер доставляемого сообщения (delivery payload) = 0.8KB
Расчет: Операции доставки/день (delivery ops/day) = 40M, средняя нагрузка ≈ 463 ops/sec. При пике 6x получаем ~2.8K ops/sec по каналам доставки.
Главная сложность: Основная сложность: обратное давление (backpressure), шторм повторов (retry storm) и приоритизация каналов при деградации внешних провайдеров (downstream providers).
Кейс 3: Кэш ленты (Timeline cache)
- 10M DAU
- 20 чтений ленты на пользователя в день (timeline reads/user/day)
- рабочий набор (working set) = 15% пользователей
Расчет: Чтения/день (reads/day) = 200M, средний RPS ≈ 2 315. Активные пользователи в горячем контуре (hot users) ≈ 1.5M. При 8KB на объект кэша (cached item) это ~12GB базового горячего набора (hot set) без накладных расходов (overhead).
Главная сложность: Ключевая сложность: удержать нужную долю попаданий (hit ratio) и контролировать инвалидацию кэша (cache invalidation) без эффекта шторма запросов (stampede).
Кейс 4: Сервис заказов (пиковые записи, write-heavy)
- 30M заказов/день (orders/day)
- размер строки (row size) = 2.5KB
- фактор репликации (replication factor) = 3
Расчет: Чистый объем записей/день (raw writes/day) ≈ 75GB. С учетом RF=3 получаем 225GB/day + индексы/метаданные (index/metadata, часто +30-60%).
Главная сложность: Главный риск: задержка пути записи (write path latency) и горизонт роста хранилища (storage growth horizon), а не только текущий QPS.
Как быстро понять главную сложность задачи
Ограничение по процессору (CPU-bound)
Высокая загрузка (utilization) при умеренном вводе-выводе (I/O): тяжелая бизнес-логика, сериализация, шифрование.
Ограничение по памяти (memory-bound)
Высокая текучесть объектов (churn), паузы сборщика мусора (GC pauses), промахи кэша (cache misses), рост хвостовой задержки (tail latency) при ограниченном бюджете RAM (RAM budget).
Ограничение по хранилищу (storage-bound)
Растет глубина очереди (queue depth), достигается насыщение IOPS на чтение/запись, операции уплотнения и сброса (compaction/flush) начинают доминировать.
Ограничение по сети (network-bound)
Межсервисные вызовы и рассылка в несколько получателей (fan-out) съедают бюджет задержки (latency budget), растет число повторных передач (retransmit) и чувствительность к потере пакетов (packet loss sensitivity).
Антипаттерны примерных оценок
Считать только средние значения и игнорировать пиковый трафик (peak traffic) и поведение во всплесках (burst behavior).
Не разделять путь чтения и записи (read/write path): усреднение прячет реальные узкие места (bottlenecks).
Оценивать хранилище (storage) без накладных расходов индексов (index overhead), фактора репликации (replication factor) и горизонта хранения (retention horizon).
Рисовать красивую схему до оценки бюджета задержки (latency budget) и ограничений емкости (capacity constraints).
Не добавлять операционный запас (operational headroom), будто система всегда работает в идеальных условиях.
Хорошая сессия примерных оценок (estimation session) заканчивается не только цифрами, но и явным ответом: что ограничивает систему первым и как это масштабировать.
Связанные главы
- Принципы проектирования масштабируемых систем - задает базовую рамку (framework) для качества сервиса и системных компромиссов.
- Балансировка трафика - помогает связать расчет пикового RPS (peak RPS) с реальной стратегией распределения трафика.
- Стратегии кэширования - углубляет оценку рабочего набора в памяти (RAM working set), доли попаданий (hit ratio) и стоимости промаха кэша (cache miss).
- Репликация и шардинг - покрывает рост хранилища (storage growth), горячие шарды (hot shards) и перераспределение (rebalancing) после оценок емкости (capacity).
- Event-Driven Architecture - добавляет расчет пропускной способности и очереди накопления (throughput/backlog) для асинхронных конвейеров (pipeline) и очередей.
- URL Shortener - практический кейс, где примерные оценки (back-of-envelope) сразу переводятся в архитектурные решения.
- Notification System - показывает расчет рассылки в несколько получателей (fan-out) и влияние семантики доставки (delivery semantics) на размер инфраструктуры.
- Rate Limiter - дополняет главу механизмами контроля всплесков трафика (burst traffic) и защитой критичного пути (critical path).