Чего ждать от System Design. Испытание кругозором на входе в FAANG

Собеседование по проектированию проверяет ваши навыки построения высокоуровневых архитектур для современных нагруженных приложений, умение обосновывать выбранные решения, спускаться до технических деталей, видеть как работает приложение целиком.

В большинстве своём это задания на построение какого-либо веб-сервиса. Клиентами веб-сервиса бывают или браузеры, или мобильные приложения, или все сразу. У меня есть подозрение, что опыт работы в нагруженном бэкенде является мощным преимуществом для этого вида собеседования. А вот узкий опыт разработки только десктоп-приложений, мобильных приложений или фронта снижает вероятность пройти это интервью без дополнительной подготовки.

Примеры заданий

Вот примерные формулировки заданий на проектирование:

1. Спроектируйте сервис создания коротких ссылок наподобие bitly.com.
2. Популярное мобильное приложение. Требуется подсчитать ежедневный процент активных пользователей, у которых приложение падало с ошибкой.
3. Популярный веб-сайт. Поле ввода для поиска по сайту. Требуется добавить показ подсказок с популярными поисковыми запросами по мере набора текста.

Как видите, вопросы очень открытые, но предполагается определённая схема ответа, и как обычно, времени на всё впритык. Обращу внимание на подводные камни. В первом вопросе будет проблемой добиться уникальности максимально коротких URL, генерируемых кластером машин. Во втором вопросе будет куча проблем вокруг повторных крэшей на одном устройстве, переинсталляции приложений, регулярное отсутствие интернета у мобильного телефона, сложность определения, что такое «активный пользователь», например, у мессенджера. Многие из этих проблем не кажутся проблемами, когда вы о них тут читаете, но их можно просто упустить из виду. В третьей задаче сразу всё сложно и проблем много.

План ответа

Во-первых, начинаем с уточнения деталей. Правильно ли мы понимаем суть задачи, сколько предполагается посетителей в сутки, какой будет поток запросов, объёмы данных. На некоторые важные вопросы у собеседующего может не быть ответов, тогда делайте свою грубую оценку. Умение делать оценки и обосновывать их будет тоже учитываться.

Потом рисуем на специальном сайте высокоуровневую схему приложения. Обычно это блоки вида «мобильное приложение», «браузер», «балансировщик», «кластер бэкенд машин», «кластер машин с фронтендом», «распределённая база данных» и далее по вкусу и смыслу. Часто добавляются дополнительные специализированные базы данных, дополнительные веб-сервисы, кэши, очереди сообщений между ними и т. п. Как и в алгоритмическом интервью, желательно пояснять, что вы делаете и зачем, а не рисовать молча.

Далее прорисовываем детали с упором на те части, которые вам более знакомы. Можно выбрать фреймворк для фронтенда, выбрать язык и фреймворк для бэкенда. Для каждого узла схемы не забудьте нарисовать и пояснить, будет ли это одна копия или же кластер. Для очередей сообщений определитесь, как с ней будут общаться читатели — активно читать (long polling) или подписываться и получать уведомления о новых сообщениях. Часто собеседующий сам может вас спросить про детали, если ему покажется недостаточной их проработка.

Обязательно выберите тип базы данных (БД) и конкретный продукт этого типа. У меня был целый лист со шпаргалкой по выбору БД, так как большинство этих баз я видел только на картинке. Обязательно обоснуйте, почему у вас, скажем, реляционная БД, а не колоночная NoSQL. Почему выбрали MySQL, а не конкурента?

Пример обоснования выбора БД: 

«Я выбрал реляционную базу данных, потому что для нашего финансового сервиса крайне важно поддержание целостности данных; это будет MySQL, а не Oracle, потому что у неё лицензия сильно дешевле, а также у нас нагрузка предполагается не столь высокая».

Следующий этап — описать схему базы данных, описать схему данных в сообщениях очереди (если они есть).

Ещё обязательная часть ответа — это описать API серверов. API я обычно описывал как функции с типизированными аргументами и возвращаемыми значениями. Обычно нет нужды спускаться слишком близко к HTTP.  Хорошим ходом может быть заложить возможность вернуть ошибку в ходе выполнения запроса, заложить такие вещи, как асинхронность, идемпотентность и т.п, но у меня для таких нюансов обычно не хватало времени.

Последним штрихом будет показать, как работает типичный сценарий. Какие при этом будут генерироваться запросы, через какие модули они будут проходить, кто их будет обрабатывать, как данные для ответа будут собираться, как данные будут растекаться по системе (если такое предусмотрено).

Например, типичный сайт с кнопкой «лайкнуть пост» будет работать примерно так:

1. Серия запросов от браузера загрузит фронтенд через балансировщик и кластер серверов фронтенда. Поясните, почему запрос попал на обработку именно серверу фронтенда, а не бэкенду.
2. Пользователь кликает на иконке в браузере, от чего джаваскрипт фронтенда генерирует запрос, который проходит через балансировщик и попадает в кластер бэкенда.
3. Бэкенд проверяет в реляционной базе, голосовал ли человек раньше, обновляет счётчик голосов. После этого возвращает новое значение счетчика браузеру.

Частые ошибки:

• Забыть упомянуть, что вам нужна не одна машина, а кластер.
• Забыть про фронтенд (забыть его нарисовать или забыть про существование запросов к его серверам).
• Забыть про балансировщик.
• Забыть про кэш.

У разных компаний FAANG в основном похожие требования к проектированию. Но у Amazon, кроме обычного проектирования, было и дополнительное смешанное интервью: проектирование с кодированием. Это неожиданный формат, где мне приходилось писать псевдокод для веб-сервиса, описывающий решение задачи. Было немного и алгоритмического (базовые вещи), и взаимодействие с клиентами сервиса. Например, итеративно решались вопросы недоверия клиенту, пытающемуся читерить, добавлялась асинхронность обработки длительных запросов от клиента. Всё это лишь псевдокод, надо показать правильные намерения и принципиальную возможность решить задачу указанным вами способом.

Если вы молодой разработчик, то провал проектирования может сильно не влиять на получение предложения о работе. Просто вы получите предложение на позицию ниже. Кажется, это интервью могут вообще не дать претендентам на невысокую позицию, но это не точно.

Полезные ссылки

CAP-теорема (очень полезно почитать, если вы не слышали о ней раньше)

Официальное видео от Amazon «Amazon System Design Preparation (SIP)»

Стороннее демо-интервью «Amazon System Design Interview: Design Parking Garage»

Стороннее демо-интервью «Facebook System Design Interview: Design Twitter»

Послесловие

Надеюсь, мой опыт собеседований, описанный в данной серии статей, кому-нибудь пригодится, чтобы вдохновиться, трезво оценить силы и пройти этот путь с успехом. В конечном итоге выучить недостающее и натренироваться проходить интервью вполне реально. Я убеждён, что знания, приобретённые в процессе подготовки, обогащают нас как специалистов в computer science. Если задуматься, то можно ли считаться хотя бы начинающим специалистом в computer science человеку, который не может решать таких задач по алгоритмизации? И можно ли в наше время интернета считаться опытным специалистом человеку, который не способен решать такие задачи по проектированию?