System Design
Оценка нагрузки (Back-of-Envelope)
Цели урока
- Знать ключевые числа для быстрых расчётов (100K секунд в дне)
- Уметь рассчитывать QPS из DAU
- Уметь оценивать Storage с учётом всех факторов
- Уметь рассчитывать Bandwidth
- Понимать пороги для выбора архитектуры
Предварительные знания
- Функциональные и нефункциональные требования
- Базовые понятия: DAU, QPS, latency
Откуда взялась «обратная сторона конверта»
Выражение back-of-the-envelope появилось в физике: Энрико Ферми в 1945 году оценил мощность первой атомной бомбы по разлёту клочков бумаги - без приборов, с точностью до порядка. Его метод «задач Ферми» стал стандартом быстрой оценки в науке и инженерии. В System Design интервью Google и Amazon ввели back-of-envelope как обязательный этап в 2008-2010 годах: кандидат должен показать, что понимает физические ограничения системы до начала проектирования архитектуры.
Зачем нужны расчёты на салфетке
2006 год. Стартап из Сан-Франциско запускает видеохостинг и через 48 часов падает под нагрузкой. Инженеры не рассчитали: при 10 000 пользователей в день каждый смотрит 3 видео по 5 минут - это 2.5 TB трафика в сутки, 29 MB/s непрерывно. Один сервер с сетевой картой на 100 Mbit/s просто физически не мог справиться. Этот расчёт занял бы 3 минуты на листке бумаги - но его не сделали. Back-of-envelope estimation - это умение за 2-3 минуты вычислить порядок величины нагрузки и понять, какая архитектура вообще возможна.
Представь: тебя спрашивают 'сколько серверов нужно для Twitter?' - и ждут ответ через 2 минуты.
- На интервью время ограничено - нужно быстро оценить масштаб
- В production важно понять порядок: это 1GB или 1TB? 100 QPS или 100K?
- Правильная оценка определяет архитектуру: монолит vs микросервисы
На интервью не нужна точность до байта. Важно правильно определить **порядок величины**: это гигабайты или терабайты? Сотни запросов или миллионы?
Почему на System Design интервью важны приблизительные расчёты?
Числа, которые нужно помнить
Есть набор чисел, которые полезно помнить наизусть. Они позволяют быстро делать расчёты в уме.
Время
| Период | Точное значение | Для расчётов |
|---|---|---|
| Секунд в минуте | 60 | 60 |
| Секунд в часе | 3,600 | ~4K |
| Секунд в сутках | 86,400 | ~100K (10⁵) |
| Секунд в месяце | 2,592,000 | ~2.5M |
| Секунд в году | 31,536,000 | ~30M (3×10⁷) |
**100K секунд в сутках** - золотое число! Запомни его: для расчёта QPS просто дели дневную нагрузку на 100,000.
Размер данных
| Единица | Bytes | Степень 10 |
|---|---|---|
| 1 KB (килобайт) | 1,000 | 10³ |
| 1 MB (мегабайт) | 1,000,000 | 10⁶ |
| 1 GB (гигабайт) | 1,000,000,000 | 10⁹ |
| 1 TB (терабайт) | 1,000,000,000,000 | 10¹² |
| 1 PB (петабайт) | 10¹⁵ | 10¹⁵ |
Латентность операций
| Операция | Время | Относительно |
|---|---|---|
| L1 cache hit | 1 ns | 1x |
| L2 cache hit | 4 ns | 4x |
| RAM access | 100 ns | 100x |
| SSD random read | 16 μs | 16,000x |
| HDD seek | 2 ms | 2,000,000x |
| Сеть: один датацентр | 0.5 ms | 500,000x |
| Сеть: SF → NYC | 40 ms | 40M x |
| Сеть: SF → Европа | 80 ms | 80M x |
Сколько примерно секунд в сутках (для быстрых расчётов)?
Расчёт QPS (Queries Per Second)
**QPS** (Queries Per Second) - главная метрика для понимания нагрузки на систему. От неё зависит, сколько серверов нужно, нужен ли кэш, load balancer и т.д.
Пример: Twitter Read QPS
Рассчитаем нагрузку на чтение для Twitter
Исходные данные: • DAU = 200M пользователей • Каждый читает ленту 5 раз в день • Каждое чтение = запрос 20 твитов Read QPS = (200M × 5) / 100K = 1B / 100K = 10K QPS (запросов к API) Но каждый запрос читает 20 твитов из БД: DB Read QPS = 10K × 20 = 200K QPS
**Peak QPS** обычно в 2-3 раза выше среднего! Для Twitter: peak = 200K × 3 = 600K QPS. Система должна выдерживать пики.
Read vs Write Ratio
Большинство систем **read-heavy** - читают данные намного чаще, чем пишут. Это влияет на архитектуру: можно агрессивно кэшировать и использовать read replicas.
| Система | Read:Write | Следствие |
|---|---|---|
| 1000:1 | Можно кэшировать ленту целиком | |
| 100:1 | CDN для изображений критичен | |
| Мессенджер | 10:1 | Нужна быстрая запись тоже |
| Биржа | 1:1 | Нужна сильная консистентность |
У сервиса 50M DAU, каждый делает 10 действий в день. Какой QPS?
Расчёт Storage (хранилища)
Расчёт хранилища важен для выбора базы данных и планирования инфраструктуры. Формула простая, но нужно учесть все составляющие.
Пример: Twitter Storage на 5 лет
Сколько места нужно для хранения твитов?
Исходные данные: • 500M твитов в день • Средний твит: 280 символов ≈ 300 bytes • Метаданные: ~200 bytes (author_id, timestamp, etc) • Итого на твит: ~500 bytes Daily Storage: = 500M × 500 bytes = 250 GB/день (только текст!) 5 лет: = 250 GB × 365 × 5 = 456 TB ≈ 500 TB текста С учётом индексов (×1.2) и репликации (×3): = 500 TB × 1.2 × 3 = 1.8 PB
**Медиа - это другой порядок!** Если 20% твитов с фото (~1MB): 500M × 0.2 × 1MB = 100TB/день. За 5 лет: 180 PB только медиа!
Типичные размеры объектов
| Объект | Размер | Примечание |
|---|---|---|
| UUID/ID | 16 bytes | Или 8 bytes для BIGINT |
| Timestamp | 8 bytes | Unix timestamp |
| 50-100 bytes | Средняя длина | |
| Username | 20-50 bytes | UTF-8 |
| Tweet/Post | 300-500 bytes | С метаданными |
| User profile | 1-2 KB | Без аватара |
| JPEG (сжатый) | 100-500 KB | Для web |
| Фото оригинал | 2-5 MB | DSLR камера |
| Видео (1 мин) | 10-50 MB | После сжатия |
Сервис хранит 100M записей по 1KB каждая. Сколько GB нужно?
Расчёт Bandwidth (пропускной способности)
**Bandwidth** - это объём данных, передаваемых в секунду. Критичен для понимания требований к сети и CDN.
Пример: Twitter лента
Рассчитаем bandwidth для отдачи ленты
Исходные данные: • Read QPS: 10K запросов к API • Каждый ответ: 20 твитов с превью • Размер ответа: ~100KB (твиты + мета + превью) Bandwidth: = 10K × 100KB = 1,000,000 KB/s = 1 GB/s = 8 Gbps Peak (×3): = 24 Gbps
**24 Gbps** - это серьёзный трафик. Один 10Gbps сервер не справится. Нужны: CDN для статики, сжатие (gzip), несколько edge серверов.
Bandwidth для разных типов контента
При 5K QPS и среднем ответе 200KB, какой bandwidth в GB/s?
Масштабирование по уровням нагрузки
Зная QPS, можно определить необходимую архитектуру. Вот практические пороги для принятия решений:
Сколько серверов нужно?
При каком QPS обычно нужно переходить от single server к load balancer?
Шпаргалка по оценке
- **Секунд в день** ≈ 100K (86,400)
- **QPS** = (DAU × actions) / 100K
- **Storage** = objects × size × retention
- **Bandwidth** = QPS × response_size
- **Peak** = Average × 2-3
- **Read:Write** - обычно 10:1 или 100:1
- **< 100 QPS** → Single server
- **100-10K QPS** → Load balancer + replicas
- **10K-100K QPS** → Microservices + sharding
- **> 100K QPS** → Geo-distributed
Как это связано с архитектурой
Результаты расчётов определяют выбор компонентов
- Load Balancer — Нужен при QPS > 100-1000
- Кэширование — Критично при read-heavy нагрузке (Read:Write > 10:1)
- Шардирование — Нужно когда данные не влезают в один сервер