Оценка нагрузки: RPS, объём данных, back-of-the-envelope

↑ 8.4 Backend System Design · ← Предыдущая · → Следующая

Обязательно~3 мин чтенияУровень: senior

Зачем это на собесе

Быстрая прикидка чисел задаёт архитектуру: 100 RPS и 100 000 RPS — разные системы.

Объяснение

Опорные числа:

ВеличинаЗначение
Секунд в сутках86 400 (≈ 10⁵)
Секунд в месяце≈ 2,6 · 10⁶
1 млн запросов в сутки≈ 12 RPS
100 млн запросов в сутки≈ 1 150 RPS
Пик/среднееобычно 2–10×
Чтение из памяти~100 нс
Чтение SSD~100 мкс
Круг внутри дата-центра~0,5 мс
Между континентами~150 мс
Один сервер приложениятысячи RPS (простая логика)
PostgreSQL на одном узле~10–50 тыс. простых запросов/с (зависит от запросов)
Redis~100 тыс. операций/с на узел

Формулы:

RPS = DAU × запросов_на_пользователя_в_день / 86 400
Пик = RPS × коэффициент_пика
Хранилище = записей_в_день × размер_записи × срок_хранения × коэффициент_репликации
Пропускная способность = RPS × размер_ответа
Кэш = 20% самых горячих данных → покрывает ~80% запросов (правило Парето)

Пример (URL shortener): 100 млн новых ссылок в месяц, чтение:запись = 100:1.

  • Запись: 100 млн / 2,6 · 10⁶ ≈ 40 записей/с.
  • Чтение: ≈ 4 000 RPS (пик ≈ 20 000).
  • Хранение: 100 млн × 500 Б = 50 ГБ в месяц → 3 ТБ за 5 лет.
  • Кэш горячих 20%: часть данных умещается в память Redis.

Вывод из оценки: чтения преобладают → кэш и реплики; объём данных умеренный → шардирование не срочно.

Нюансы и подводные камни

  • Округляйте: цель — порядок величины, а не точность.
  • Учитывайте пики, а не только среднее.
  • Проверяйте вывод здравым смыслом (одного узла достаточно или нет).
  • Не забывайте про метаданные, индексы, репликацию, бэкапы (×2–3 к объёму).

Практика

  1. Прикиньте RPS и хранилище для мессенджера на 10 млн DAU.
  2. Оцените, хватит ли одного PostgreSQL для системы из примера.
  3. Запомните 10 опорных чисел.

Вопросы с ответами

Связанные темы