Дизайн-интервью

План интервью

Будем считать что тайм-слот интервью - 40 минут.

1. Уточнить требования и ограничения (4 минуты)
2. Сделать эстимейты проектируемой системы (пропускная способность, сколько нужно хранить информации, количество серверов и т.д.) (3 минуты)
3. System interface - какие сервисы предоставляет система, какие сервисы использует система (3 минуты)
4. System high-level design - какие компоненты входят в систему, как они взаимодействуют друг с другом (5 минут)
5. Component detailed design - какие компоненты входят в систему, как они взаимодействуют друг с другом. Описать возможные ботлнеки (15 минут)
6. Масштабирование - как система будет масштабироваться (5 минут)
7. Summary - общий обзор и презентация решения (5 минут)

1. Сбор требований

Собираем ответы на вопросы “Что система делает?” и “Какой должна быть система?”

Примеры вопросов:

• Это должна быть глобальная система или региональная?
• Как быстро система должна реагировать на внесенные изменения (latency)?
• Какая должна быть доступность системы (availability)?
• Сколько у нас пользователей активно ежедневно?
• Сколько пользователи генерируют трафика ежедневно (количество постов, публикаций и тд)?
• Какое количество информации пользователь просматривает каждый день?

Если нам предлагают спроектировать систему по примеру существующей (twitter, facebook, google docs, etc), то мы можем спросить: - Какую часть системы мы проектируем? - Какие именно функции должны быть реализованы?

Сразу формируем для себя чек-лист требований, чтобы не забыть что-то важное. Например нам предложили спроектировать Facebook с такими требованиями:

• Дизайним ленту новостей (news feed) фейсбука
• Фото/видео не реализуем
• Ранжирование постов не нужно, хронологический порядок
• Встраиваем реламу в ленту (желательно)
• Глобальная система (multi-region)
• Latency (внутри региона) < 1s
• Latency (между регионами) < 60s
• Durability (постоянство данных) очень важно
• Availability (доступность) менее важно
• Миллиард пользователей
• 10 миллионов постов в день
• 500 друзей в среднем
• 5 просмотров фида на пользователя в день

2. Эстимейты

Чтобы посчитать эстимейты нужно примерно представить какой тип информации сколько весит.

Хранение информации: - Символ - 1 байт - Метаданные (строка в базе, вес поста, etc) - 5-10 килобайт - 1080p изображение - 2 мегабайта - 1080p видео (минута) - 30 мегабайт

Сервера: - Дисковое пространство - 10 терабайт - RAM - 256-512 гигабайт

Итого считаем эстимейты для примера с фейсбуком: - Read-write ratio - 5B / 10M = 500:1 - RPS - Read: 5B / (24 * 60 * 60) = ~58k rps - Write: 10M / (24 * 60 * 60) = ~115 rps - Storage: - 10KB * 10M = 100GB ежедневно - 30 * 100GB = 3TB ежемесячно - Пропускная способность: - Read: 5B * 20 постов * 10KB = 1PB ежедневно - Write: 10M * 10KB = 100GB ежедневно

PS. RPS мы посчитали “постоянный”, в пиках он может увеличиваться в 10 раз (условно)

3. API

Описываем максимально просто - какие методы будут доступны, какие параметры будут принимать.

4. High-level design

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

• Если ставим лоад-балансер, то какой? (Round-robin, sticky sessions, etc)
• Если БД, то какая? (RDBMS, NoSQL, inmemory etc)

5. Detailed design

• Описываем схему БД и запросы к ней (можем прям примеры запросов писать)
• Перебираем подходы по обработке данных (pros/cons)
• Выбираем решения и объясняем их tradeoffs
• Проверяем требования (список который мы составили на шаге 1)
• Определить edge cases (если они есть)

6. Масштабирование

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