Нефункциональные требования

• Total users - 2 миллиарда
• DAU пользователи (кто запрашивает заведения) — 1 миллиард
  • Каждый клиент делает 5 запросов в день
• DAU админы заведений (кто редактирует) — 10 миллионов
  • Заведения создаются/редактируются 2 раза в месяц
  • Количество заведений: 10 000 000
• Так как гео весь мир, то будем стараться ставить ДЦ на каждом крупном материке
• Заведение можно просматривать, поэтому необходимо заложить под это функционал карточки:
  • 1000 символов
  • изображения: 4 изображения 1МБ
• Доступность: 99.99%
  • В Неделя 6 подробно говорим про Надежность и как мапить это на цифру. Обязательно изучи
• Лимиты:
  • 300 мс на выдачу

Интересный момент про нефункциональные требования:

На собесе можно проговорить, что если какие-то требования супер сложные в реальной жизни, то мы можем вступить в переговоры с бизнесом, чтобы снизить их. Таким образом я не нужно будет городить супер сложные системы. Одна из ключевых особенностей при проектировании - простота (simplicity of your decision). Можно впасть в ловушку и делать сложные решения. А можно передоговориться с бизнесом и упростить требования.

Важный момент: на реальном интервью не нужно всегда все считать. Нужно делать только те расчеты, которые помогут тебе спроектировать систему. Если бы ты делал эту систему на собесе, то можно кратко обсудить с интервьюером, что нагрузка большая и примерно накинуть расчеты, но не разбирать до винтика.

RPS (read) для пользователей: 
1_000_000_000 * 5 / 86_400 = 57_870

RPS (read) для админов: 
(10_000_000 * (2/30)) / 86_400 = 7.7

RPS (write) для пользователей: ничего не пишут, только читают

RPS (write) для админов: 
(10_000_000 * (2/30)) = 700_000 / 86_400 = 7.7

Storage:
Количество заведений: 10 000 000
Текст: 1 000 символов × 2 байта = 2 КБ
Изображения: 4 × 1 МБ = 4 МБ
Итого на заведение: 4 002 КБ ≈ 4 МБ
Total: 10_000_000 * 4_002_000 байт = 37.3 ТБ

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

Просмотров карточек в день: 1 000 000 000
Размер карточки: 4 002 000 байт
Суточный трафик: 1_000_000_000 * 4_002_000 = 3.7 ПБ/день

Комментарии к расчетам:

1. Не считаем RPS write * storage на заведение, так как у нас не будут часто создаваться заведения
2. Для storage у нас общий расчет, который включает медиа и оставшуюся инфу. Медиа занимает гораздо бОльший процент от общей памяти. Но и хранить мы его будем в отдельном Blob Storage

Также нам нужно учесть:

1. RPS для пользователей может быть X2, если происходит burst
2. Storage не учитывает репликацию, поэтому тут нужно закладывать X2/X3

Выше мы считали данные для карточки с заведением. Но ничего не сказали про само хранение. У нас будет отдельная глава в рамках этого разбора, где мы посмотрим на нюансы. Сейчас же давай попробуем прикинуть примерно, а сколько вообще будут занимать гео-данные.

Для заведения нужны latitude, longitude, id. Каждый из них может быть от 2 до 8 байт. Возьмем по максимуму: 24 байта × 10,000,000 = 228.9 МБ

Далее, гео-данные чуть более сложно индексируются, но для прикидки можем делать следующим образом: у нас добавляет 1 колонка с весом 8 байт: 8 байт × 10,000,000 = 80 МБ