Архитектура, придуманная до оценки порядков величин, слишком часто оказывается красивой, но нерелевантной реальному масштабу задачи.
Глава показывает, как быстрые примерные оценки помогают заранее увидеть, что насыщается первым: трафик, память, диски, сеть или бюджет задержек. Это экономит время на раннем отборе решений и не даёт спорить о деталях до того, как понятен настоящий масштаб.
На интервью по системному дизайну это один из самых сильных сигналов зрелости: сначала назвать разумные допущения и главное ограничение, а уже потом предлагать архитектуру, которая действительно соответствует обнаруженному масштабу.
Практическая польза главы
Оценка за минуты
Быстро переводите продуктовый сценарий в числа: RPS, объём трафика, рост хранения и порядок инфраструктурных ограничений.
Главное узкое место
Через оценки памяти, хранилища, сети и бюджета задержек определяйте, какой слой упрётся первым и где нужен архитектурный запас.
Выбор решения
Связывайте расчёты с выбором кэша, репликации, шардинга, асинхронной обработки и целевых уровней сервиса.
Подача на интервью
Показывайте на интервью чёткую структуру: допущения, формулы, главный риск и следующий шаг эволюции системы.
Источник мышления
Designing Data-Intensive Applications, 2nd Edition
Хорошая опора для разговора о пропускной способности, росте хранилища и компромиссах между скоростью ответа и стоимостью системы.
Примерные оценки (Back-of-Envelope Estimation) нужны не для того, чтобы угадать идеальную цифру. Их задача — за первые минуты понять порядок величин, ожидаемую и первое .
До выбора технологий полезно зафиксировать ключевой , ожидаемые и , а затем разложить по слоям системы. Тогда становится видно, где именно архитектура упрётся первой.
Быстрые константы и единицы
Время
- 1 день = 86 400 с
- 1 месяц ≈ 30 дней
- Пиковая нагрузка часто в 2-5 раз выше средней
Трафик
- RPS = requests/day / 86 400
- RPS_peak = RPS_avg * коэффициент пика
- Чтения и записи лучше считать отдельно
Байты
- 1 KB = 10^3 B
- 1 MB = 10^6 B
- 1 GB = 10^9 B
Пропускная способность
- байт/с = RPS * размер ответа
- бит/с = байт/с * 8
- Добавляйте накладные расходы протокола
Память
- RAM = горячий рабочий набор
- Добавьте расход на соединения и сессии
- Оставляйте резерв 20-30%
Хранилище
- storage/day = writes/day * average_row_size
- Добавьте индексы и метаданные
- Умножьте на фактор репликации
Шаблон оценки за 5 шагов
Пяти шагов обычно хватает, чтобы перейти от продуктового сценария к числам. Сначала переводим разговор в RPS и , затем учитываем для устойчивого максимума, для коротких скачков и отдельно смотрим на , если именно он определяет цену данных.
Шаг 1
Зафиксируйте допущения
Определите аудиторию, ключевой путь пользователя, долю чтений и записей, размер запроса и ответа, а также ожидаемый уровень сервиса.
Шаг 2
Переведите продуктовые метрики в нагрузку
Посчитайте средний и пиковый RPS, отделите постоянный пик от коротких всплесков и отдельно отметьте самый дорогой путь записи.
Шаг 3
Оцените ресурсы по слоям
Отдельно прикиньте память для горячих данных и кэша, рост хранилища, а также сетевой обмен между сервисами и наружу.
Шаг 4
Разложите бюджет задержек
Распределите бюджет между пограничным слоем, приложением, кэшем, базой данных и внешними зависимостями.
Шаг 5
Найдите первое ограничение
Определите, что упрётся первым при росте в 5-10 раз: CPU, память, сеть, дисковые операции или операционная сложность.
От трафика к RPS: базовые формулы
Средняя и пиковая нагрузка
requests/day = DAU * requests_per_user/day
RPS_avg = requests/day / 86 400
RPS_peak = RPS_avg * peak_factor
Разделение чтений и записей
RPS_read = RPS_total * read_ratio
RPS_write = RPS_total * write_ratio
путь записи обычно задаёт требования к хранилищу и долговечности данных
Одного среднего значения почти никогда не хватает. Для решений по архитектуре важно видеть не только RPS, но и : именно он показывает, как реальная ведёт себя в неприятной, но вполне рабочей части распределения.
Оперативная память и постоянное хранилище
По памяти нас интересует горячий набор, который нужен для быстрого ответа. По диску — суточный прирост, индексы, метаданные и , без которой оценка объёма хранения обычно оказывается слишком оптимистичной.
Оперативная память
Начинайте с горячих данных и кэша, которые нужны для целевой скорости ответа. Затем добавляйте накладные расходы соединений, сессий и запас на реальные колебания нагрузки.
Горизонт хранения
storage/day = writes/day * average_row_size
total/day = storage/day * replication_factor * (1 + index_overhead)
storage/N months = total/day * 30 * N
Сетевая пропускная способность и исходящий трафик
Считайте отдельно и . Для каждого межсервисного перехода полезно начать с формулы bytes/sec = RPS * payload, а затем добавить заголовки, шифрование, ретраи и . Это быстро показывает, где понадобится сжатие, пакетирование или пересборка API-контракта.
Как разложить бюджет задержек
Если суммарный бюджет уже близок к целевому уровню сервиса, главным риском становится . Именно она первой ломает красивую картину из средних значений.
4 мини-кейса с быстрыми выводами
В быстрых оценках важно не только число, но и характер проблемы. Где-то первым всплывает , где-то — , где-то — , а в более тяжёлых контурах быстро становятся заметны , и .
Кейс 1: сервис коротких ссылок
- 100 млн переходов в день
- ответ ≈ 1,2 KB
- коэффициент пика = 3x
Расчёт: RPS_avg ≈ 1 160, RPS_peak ≈ 3 500. Пиковый исходящий трафик ≈ 4,2 MB/s (~34 Mbps) до учёта шифрования и заголовков.
Главная сложность: Сложность чаще всего не в объёме хранения, а в доле попаданий в кэш и задержке на чтении.
Кейс 2: рассылка уведомлений
- 5 млн событий в день
- средняя раздача = 8 получателей
- сообщение ≈ 0,8 KB
Расчёт: Операций доставки в день = 40 млн, средняя нагрузка ≈ 463 ops/sec. При пике 6x получаем около 2,8 тыс. ops/sec по каналам доставки.
Главная сложность: Главные риски — переполнить очереди доставки, не допустить каскада повторов и сохранить приоритет важных каналов.
Кейс 3: кэш ленты
- 10 млн DAU
- 20 чтений ленты на пользователя в день
- рабочий набор = 15% аудитории
Расчёт: Чтений в день = 200 млн, средний RPS ≈ 2 315. Активный горячий контур ≈ 1,5 млн пользователей. При 8 KB на объект это около 12 GB базового набора без накладных расходов.
Главная сложность: Главная сложность — удержать высокую долю попаданий в кэш и не превратить его инвалидацию в шторм запросов.
Кейс 4: сервис заказов с тяжёлым путём записи
- 30 млн заказов в день
- размер строки = 2,5 KB
- фактор репликации = 3
Расчёт: Чистый объём записей ≈ 75 GB/day. С учётом RF=3 получаем 225 GB/day плюс индексы и метаданные, которые легко добавляют ещё 30-60%.
Главная сложность: Самый дорогой участок здесь — путь записи и долгосрочный рост хранилища, а не только текущая интенсивность записи.
Как быстро увидеть реальную сложность задачи
Упирается в CPU
Высокая загрузка процессора при умеренном I/O: тяжёлая бизнес-логика, сериализация или шифрование.
Упирается в память
Высокая текучесть объектов, паузы GC, промахи кэша и рост хвостовой задержки при тесном бюджете RAM.
Упирается в хранилище
Растёт глубина очереди, насыщаются IOPS на чтение и запись, а фоновые операции начинают доминировать во времени ответа.
Упирается в сеть
Межсервисные вызовы съедают запас по задержке, а любые лишние переходы резко увеличивают цену каждого запроса.
Антипаттерны примерных оценок
Считать только средние значения и игнорировать реальный пик и короткие всплески.
Смешивать путь чтения и путь записи в одну цифру, скрывая настоящее узкое место.
Оценивать хранилище без индексов, репликации и горизонта хранения.
Сначала рисовать красивую схему, а потом пытаться втиснуть её в бюджет задержек и ёмкости.
Не оставлять эксплуатационный запас, как будто система всегда работает в идеальных условиях.
Хорошая сессия примерных оценок заканчивается не только цифрами, но и ясным ответом: что ограничит систему первым и какой следующий архитектурный шаг это потребует.
Связанные главы
- Принципы проектирования масштабируемых систем - дают базовую рамку качества системы и помогают связать оценки с архитектурными ограничениями.
- Балансировка трафика - помогает перевести пиковый RPS в реальную стратегию распределения запросов и защиты от перегрузки.
- Стратегии кэширования - углубляют тему горячего набора, доли попаданий и цены промаха кэша.
- Репликация и шардинг - объясняют, как после оценки роста данных выбирать между репликацией, шардингом и перераспределением нагрузки.
- Event-Driven Architecture - добавляет расчёт очередей и асинхронных конвейеров, когда система уходит от прямых вызовов.
- URL Shortener - показывает, как быстрые оценки сразу превращаются в архитектурные решения.
- Notification System - даёт прикладной пример рассылки по многим каналам и её влияния на размер инфраструктуры.
- Rate Limiter - дополняет тему контролем всплесков и защитой критичного пути.