SYSTEM DESIGN
Часть 1

Прошлая чать серии по собеседованиям тут.

Всех приветствую! Наконец-то мы дожили до наверное самой потной части по собеседованиям. Причем эта сложность обеспечивается не большим объемом теоретического материала, но и необходимостью почти многое применить на практике. То есть для поверхностного понимания будет достаточно теоретического материала, но для более глубокого погружения обязательно необходим опыт (по крайней мере так часто говорят)! Это собеседование уже проводят на высокие позиции в разработке, обычно начиная с синьорской. В FAANG кстати такой этап может случиться и при прохождении интервью на джуна. Поэтому рекомендую вам хотя бы ознакомиться и понять, что же здесь происходит. Также прошу здесь учесть некоторое предостережение, что мой опыт в таких собеседованиях не очень большой, поэтому это субъективно и может отличаться от кейса к кейсу.

По своему формату это собеседование очень похоже на ML System Design - берем условие и задачу, актуализируем требования и далее начинаем повествование о том, как это можно решить. Здесь точно так же идет первоначальная постановка задачи, обсуждение входных параметров и условий работы сервиса. После идет реализация некоторого базового сценария под вышеприведенные условия и либо дальнейшее его масштабирование и усовершенствование, либо погружение в детали. Например, первоначальная постановка вопроса может звучать так: “Спроектируйте мне сервис, похожий на Яндекс.Карты”.

Структуру собеседования можно разложить на следующие этапы:

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

Здесь наша задача состоит в том, чтобы уточнить как можно больше информации о том, чего же от нас хотят. Сколько мы хотим видеть юзеров ежедневно? Является ли наш сервис критически важным и следовательно нужно ли нам строго минимизировать вероятность его недоступности. Обычно в этом блоке требования разделяются на 2 категории: функциональные и нефункциональные. Функциональные требования - это те фичи, которые предоставляет ваш сервис (найти ближайший магазин, загрузить отзывы, посчитать время в пути, оставить отзыв, получить рекомендации). Нефункциональные - это можно обозначить как его свойства (доступность, быстрый отклик, возможность одновременно принимать большое количество юзеров).

2. Приведение нефункциональных требований к базовым метрикам.

Допустим, мы разобрали все основные требования к сервису, которые мы хотим видеть. Теперь это нужно преобразовать в понятные для нас цифры, с которыми мы постараемся поработать. Допустим мы остановились на доступности - надо детальнее проработать, что это обозначает и в виде каких метрик мы можем это рассмотреть: например latency (задержка между кликом и реакцией системы) можем допустить 150 мс, или стоит все же взять 50 мс, если нам нужно быстрое взаимодействие. Ну или SLA 99.99 (процент времени работы сервиса без простоев). Обязательно нужно подумать над средним количеством юзеров в секунду и количеством операций, которое нам необходимо обеспечить - при этом следует оценить сколько из этого операций на чтение, а сколько на запись. По хорошему перед этим моментом желательно уже понимать не только важные концепции, используемые при дизайне систем: (CAP, ACID, scaling, monolith vs. microservices), но и разбираться в компонентах: Load balancers, API, Cashing. Очень многое тут не упомянуто, поэтому кидаю ссылку на базу.

Продолжение ниже ⬇️

#systemdesign #interview