Сегодня немного обсудим один из видов технических интервью — System Design.
Обычно это секция, где вам дают около часа на задачу с открытым ответом: «спроектируйте Amazon», «спроектируйте сервис такси» и т.д. Правильного ответа тут, в отличие от алгоритмической задачи, нет. Будут оценивать, как вы согласовываете требования, о чем думаете при проектировании системы, какие архитектурные паттерны используете. Такую секцию обычно не дают на младшие грейды (чаще Senior+).
Несмотря на то, что задача открытая, есть более-менее стандартный план, которому удобно следовать во время ответа. Сохраняйте себе как шпаргалку.
5–10 минут — сбор требований
Это один из самых важных этапов. Задача обычно сформулирована очень абстрактно. Если кандидат сразу бросается что-то рисовать — это скорее негативная отметка. В реальной работе так тоже не делают.
Даже если вас просят спроектировать Amazon и вы прекрасно знаете, что это такое, за час вы не сможете спроектировать весь Amazon. Только запутаете себя. Поэтому сначала уточняем требования.
1️⃣ Функциональные требования
Определяем, на каком сценарии фокусируемся.
Например, если проектируем покупку товара:
⬛поиск по тексту (и больше ничего: без фильтров, рекомендаций, скидок и т.д.);
⬛выбор товара из результатов поиска;
⬛добавление в корзину;
⬛покупка.
Максимально упрощаем себе жизнь, но оставляем базовый пользовательский сценарий.
2️⃣ Нефункциональные требования
Именно они сильнее всего влияют на архитектуру.
Например:
⬛сколько одновременно ожидается пользователей;
⬛сколько товаров хранится в системе;
⬛предполагается ли рост нагрузки;
⬛должен ли сервис работать 24/7 или только в рабочее время;
⬛нужен ли ответ пользователю мгновенно или подтверждение покупки можно отправить через час.
Ответ на каждый из этих вопросов влияет на итоговый дизайн.
15–20 минут — высокоуровневый дизайн
Проектируем API.
Например:
1️⃣search
Вход:
{
"text": "iphone"
}
Выход:
{
"products": [
{
"id": 1,
"name": "Best One",
"price": 100
}
]
}
2️⃣add-to-cart
Вход:
{
"id": 1,
"count": 5
}
Выход:
yes / no
3️⃣buy
Вход:
{}
Выход:
yes / no
Дальше набрасываем модель данных:
⬛описание товара;
⬛стоимость;
⬛остатки на складе;
⬛изображение товара.
Потом рисуем архитектуру.
Например:
🤩сервис поиска;
🤩сервис авторизации;
🤩сервис склада;
🤩сервис оплаты;
🤩база данных;
🤩балансировщик нагрузки.
В целом эти этапы можно менять местами. Но проектирование API я бы оставила первым. Очень часто именно оно помогает понять, какие компоненты вообще должны существовать в системе.
Продолжим завтра!
#бабанюра_заходит_в_айти