Этот короткий чек-лист поможет вам структурированно отвечать на вопросы по расчету нагрузки и стоимости системы на собеседовании System Design. Используйте его как пошаговый гайд, чтобы не упустить ключевые моменты.

Данная статья не претендует на полное изложение темы, однако сведения в ней, помогут вам не растеряться на собеседовании или при решении реальной задачи System Design. Сохраните себе данный чек-лист, чтобы быть всегда во все оружии.

При расчете нагрузки и стоимости системы на собеседовании по System Design важно демонстрировать структурированный подход и прагматичные оценки.

Чек-лист

1. Первым делом необходимо определить сколько всего пользователей системы? Это может быть просто общее число или подойдут значения (Daily Active Users) — ежедневно активные пользователи), (Monthly Active Users — ежемесячно активные пользователи), (Weekly Active Users — еженедельно активные пользователи). На будущее удобнее все показатели приводить к , так как большинство дальнейших расчетов зависят от этого показателя.

2. Также необходимо определить среднее число запросов от одного пользователя в день. (Можно взять верхнюю оценку если сомневаетесь).

3. п.1 и п. 2 понадобится для расчета кол-ва запросов к системе в секунду, которые считаются по формуле:
   
   ,

   где (Requests Per Second) количество запросов в секунду (1/c), - количество уникальных пользователей за день. - среднее число запросов на одного пользователя в день, - пиковый коэффициент (опционален).

4. Далее необходимо определить сколько в среднем пользователь будет находиться в системе? То есть необходимо определить cреднее время сессии. Например, если мы проектируем приложение Такси, то можем определить все целевые действия пользователя (например ввод адреса подачи и конечной точки, поиск подходящего водителя, проверка статуса заказа, проставление оценки), сколько на них необходимо потратить времяни и сколько раз он воспользуется сервисов. Отсюда мы заключаем, что средний пользовать дважды в день вызывает такси и в рамках одной поездки проводит в приложении 15 мин. Это также понадобится для расчета кол-ва одновременных соединений к системе.

5. Определяем сколько система будет активна в течении дня? (Обычно фиксируется 24 часа)

6. Из п. 4 и п. 5 можем посчитать кол-во одновременных соединений в течении дня по формуле:

   ,

   где - количество одновременных соединений, - cреднее время сессии -  как долго пользователь находится в системе (например, 10 минут), - cреднее время активности в день - общее время работы сервиса (например, 24 часа = 1440 минут).

7. После того как вы определите кол-во одновременных запросов встанет вопрос о стоимости решени. Средняя цена одного сервера может сильно колебаться в зависимости от облачных решений или закупки собственного железа. На собеседовании стоит заранее обговорить цену сервера, который способен выдержать до 100к активных соединений. Можно зафиксировать что 1 облачный инстанс в среднем стоит от 1к$ до 3к$ в месяц и может выдерживать до 100к одновременных соединений.

8. Далее определяем каков средний размер одной единицы данных которая проходит через нашу систему? (например размер лога, сообщения, записи в БД). Это потребуется для расчета пиковой нагрузки на сеть по формуле:
   
   ,
   где - пиковая нагрузка на сеть (бит/с), - средний размер одной единицы данных (например размер лога, сообщения, записи в БД) в Б, КБ, МБ и тд.

9. Теперь зная сколько нагрузки генерирует ваша система вы можете определиться с выбором тарифа и пропускной способностью за которую вы будете платить. Держим в уме, что один сетевой инстанс в среднем имеет пропускную способность 1Гбит/сек и стоит около 300$ в месяц, то есть если у нас пиковая нагрузка 2,5 Гбит/сек, то нам понадобятся 3 сетевых инстансы за 900$ в месяц.

10. Через кол-во пользователей (п.1) и среднего значения операций на одного пользователя (п.2) в единицу времени, можно рассчитать количество операций/событий в единицу времени (например в день). ТУт важно понимать, что если у вас запрос к серверу 2КБ, а ответ 10МБ, то вам нет необходимости учитывать в расчетах объем запроса, так как он несоизмеримо мал в сравнении с советом. Поэтому берите только верхнюю оценку, этого будет достаточно. Эти данные понадобитяся для расчета сетевого графика, по формуле:

    ,
    где A - сетевой трафик (Байт), - количество операций/событий в единицу времени (например в день).

11. Теперь вы можете рассчитать сумму, которую вы будете отдавать облачному провайдеры. Облачные провайдеры продают свои услуги в среднем по цене до 0.1$ за 1ГБ трафика. То есть если в день через вашу систему прошло 1ТБ графика, за это вы заплатите приблизительно 100$.

12. Далее зная количество операций/событий в единицу времени (например в день) (п.10) и средний размер одной единицы данных которая будет загружена в БД (например если мы храним данные пользовалей, то можно прикинуть кол-во пользователей и сколько будет весить данные 1 пользователя), остается только определить время хранения и мы сможем рассчитать нагрузку на хранилище в течении заданного времени, по формуле:

    , где V - объем хранимых данных (Байт) - время хранения (в секундах, часах, днях и т.д).

13. Теперь зная какое кол-во информации вам предстоит хранить на промежутке времени, вы можете подчитать сколько это будет стоить. Предлагаю ссылаться на следующие значения:

    • Цена HDD за 1ТБ: 30$.

    • Цена SSD за 1ТБ: 300$.

    • Цена RAM за 1ТБ: 10000$.

    Так как нет необходимости все данные хранить в HDD или RAM, из следует распределить в процентном соотношении и посчитать отдельно каждый тип памяти.
    

14. Договоритесь о пиковом коэффициенте, то есть о там, во сколько раз может возрасти пиковая нагрузка. Данный коэффициент потом можно использовать для расчета верхней оценки всех параметров.

Данные формулы верхнеуровнево позволят оценить показатели нагрузки на вашу систему. Каждую из этих формул можно усложнить дополнительными переменными и параметрами, которые способны внести корректировки в конечный результат вычислений. Для собеседования данные формулы отлично подходят, в прочем также как и для первичной оценки реальных систем.

Особенно важно учитывать сезонные колебания. Для одного маркетплейса мы проектировали систему, которая в обычные дни обрабатывала 1000 заказов в час, но в Чёрную пятницу нагрузка вырастала в 20 раз. Без учёта этого фактора система бы гарантированно легла в самый ответственный момент.

Подробнее по каждому показателю можно ознакомиться в моей статье с примерами - Магия чисел в System Design: эти формулы спасут вас от банкротства и помогут оптимизировать вашу систему

Советы для собеседования

1. Говорите предположения вслух  

«Я предполагаю 10:1 соотношение чтения/записи — поправьте, если это не так».  

2. Упрощайте расчеты  

1. Округляйте числа (1,000,000 вместо 1,023,456).  

2. Берите только высшие оценки по показателям. Несоизмеримо маленькие можно пустить.
   

3. Сравнивайте альтернативы  

«MongoDB дешевле на 20%, но PostgreSQL надежнее для транзакций».  

Чего избегать

• Точные расчеты без контекста: Лучше диапазоны (5к–5к–10к/мес).  

• Игнорирование региональных цен.

• Забывать про резервы: Всегда добавляйте 20–30% к расчетам.  

Спасибо за внимание!

PS

Поделитесь впечатлениями о статье или поведайте нам, как вы привыкли считать нагрузку и стоимость решения?)

PPS

Если вас интересует что-то больше чем просто расчет нагрузки и стоимости системы, например подробное описание каждого показателя, множество примеров расчета, а также вы хотите научиться принимать взвешенные архитектурные решения, которые выдержат миллионы пользователей и не сломаются при первой же проблеме. С гордостью представляю вам свой новый курс на Stepik, где представлены все этапы System Design с подробными лекциями, конспектами и практикой: C нуля до проектирования систем уровня senior-инженера. Специально для Habr действует промокод 20% HABR20 .