diff --git a/README.md b/README.md index e213b73..267aed7 100644 --- a/README.md +++ b/README.md @@ -322,6 +322,16 @@ * [Что такое VACUUM в PostgreSQL](questions.md/#Что-такое-VACUUM-в-PostgreSQL) * [Что такое EXPLAIN. Какая разница между ним и EXPLAIN ANALYZE](questions.md/#Что-такое-EXPLAIN-Какая-разница-между-ним-и-EXPLAIN-ANALYZE) * [Какие виды Join'ов вы знаете, чем они отличаются друг от друга](questions.md/#Какие-виды-Joinов-вы-знаете-чем-они-отличаются-друг-от-друга) +- [Дизайн-интервью](questions.md/#Дизайн-интервью) + * [План интервью](questions.md/#План-интервью) + * [1. Сбор требований](questions.md/#1-Сбор-требований) + * [2. Эстимейты](questions.md/#2-Эстимейты) + * [3. API](questions.md/#3-API) + * [4. High-level design](questions.md/#4-High-level-design) + * [5. Detailed design](questions.md/#5-Detailed-design) + + [Performance mantras](questions.md/#Performance-mantras) + * [6. Масштабирование](questions.md/#6-Масштабирование) + + [Performance bottlenecks](questions.md/#Performance-bottlenecks) - [Вопросы работодателю](questions.md/#Вопросы-работодателю) * [Вопросы HR'у](questions.md/#Вопросы-HRу) * [Вопросы для технического собеседования](questions.md/#Вопросы-для-технического-собеседования) diff --git a/questions.md b/questions.md index 15bdb73..6c471d8 100644 --- a/questions.md +++ b/questions.md @@ -5374,6 +5374,144 @@ USING — это сокращённая запись условия, полез Еще есть cross join - декартово произведение. +# Дизайн-интервью + +[Как задизайнить Facebook за пол часа или секреты System Design Interview / Алексей Петров](https://www.youtube.com/watch?v=Be7INI_U6GY) + +Тема очень обширная, поэтому этот раздел следует воспринимать как чеклист для его прохождения. + +## План интервью + +Будем считать что тайм-слот интервью - 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 (если они есть) + +### Performance mantras + +В процессе, если мы сталкиваемся с проблемой производительности, то мы можем применять следующие [мантры](https://www.brendangregg.com/methodology.html): +- Не делай этого +- Делай, но только один раз +- Делай это реже +- Сделай это позже +- Сделай пока пользователь этого не видит +- Сделай это параллельно +- Сделай это дешевле + +## 6. Масштабирование + +Если говорим про шардирование, то сразу оговариаем какой ключ шардирования выбираем. + +### Performance bottlenecks + +В зависимости от количества пользователей нам может понадобиться разные инфраструктурные решения: + +- 1000 пользователей + - 1 сервер + - 1 БД +- 10 000 пользователей + - Read replicas + - Несколько серверов + - Load balancer(s) +- 100 000 пользователей + - Message queue + - Rate limits + - Cache + - CDN +- 1 000 000 пользователей + - Stateless services (если они еще не такие) + - Возможно появится noSQL (если еще не использовался) + - Database sharding +- 1 000 000 000 пользователей + - Regional DCs + # Вопросы работодателю - [Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»](https://habr.com/ru/post/428283/)