Add design-interview chapter (#7)

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/#Вопросы-для-технического-собеседования)

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/)