Это моя стратегия - провести собеседование по проектированию системы, которое помогло мне взломать кучу FAANG. Вы можете попробовать то же самое!
Обычно собеседования по проектированию системы длинные и охватывают множество сложных компонентов. Это позволяет очень легко потеряться в мелочах и упустить общую картину. Поэтому очень важно структурировать интервью таким образом, чтобы вы могли легко передать всю картину, не тратя время на то, что не добавляет ценности.
Ниже представлена структура, которой я следую, и вы можете попробовать то же самое.
Проведите интервью
Убедитесь, что вы ведете собеседование, а не ваш собеседник. Это не означает, что вы не позволяете им говорить, скорее, вы должны быть тем, кто говорит большую часть, активно выявляя проблемы в вашем дизайне, прежде чем интервьюер укажет на это, обрабатывать крайние случаи, в которые интервьюер может вас ткнуть на и т. д.
FR и NFR
Четко обозначьте функциональные и нефункциональные требования. Намерение состоит в том, чтобы требования были достаточно большими, чтобы сделать задачу сложной, а также достаточно конечными, чтобы вы могли построить систему, которая удовлетворяет этим требованиям в течение установленного времени. С нефункциональной стороны попробуйте создать систему, которая работает в очень большом масштабе. Что хорошего в разработке системы, которая работает в низком масштабе?
Прежде чем доработать FR и NFR, попросите своего собеседника просмотреть их, чтобы убедиться, что они не хотят что-то добавлять / удалять. Иногда интервьюеры имеют в виду некоторые конкретные варианты использования, которые они хотят рассмотреть.
Оценка емкости
Посоветуйтесь со своим интервьюером, хотят ли они в этом разобраться. Многие люди предпочитают пропустить вычисления и больше сосредоточиться на дизайне, предполагая достаточно большое приблизительное число для количества требуемых ядер или необходимого количества диска и т. Д.
План
Основываясь на FR и NFR, придумайте следующие вещи:
- Точки взаимодействия с пользователем.
- Требования к задержке / доступности / согласованности в каждой точке взаимодействия с пользователем.
- Быстрый анализ, позволяющий определить, является ли это взаимодействие с интенсивным чтением или взаимодействием с большим объемом записи.
- Основываясь на трех вышеупомянутых, придумайте, какие все службы вам понадобятся и какие базы данных вы можете использовать для хранения данных, которыми владеет каждая из этих служб.
HLD
Придумайте диаграмму компонентов высокого уровня, которая охватывает следующее:
- Какие все сервисы присутствуют? Убедитесь, что вы разделили поток на несколько функциональных компонентов и посмотрите, имеет ли смысл подход, основанный на микросервисах, или нет. Обычно использование подхода, основанного на микросервисах, является хорошей идеей для собеседований SD.
- Как сервисы взаимодействуют друг с другом и какие протоколы используются для межсервисного взаимодействия, например Async / Sync - Rest, RPC и т. Д.?
- Как пользователи будут взаимодействовать со всей системой и с какими службами сталкиваются пользователи. Вам нужен кеш для уменьшения задержек?
- Какой сервис использует какую базу данных и почему? Вы можете обратиться к этому видео, которое поможет вам выбрать правильную базу данных в зависимости от вашего варианта использования
- Посмотрите, нужно ли вам где-нибудь кеширование, и если да, то какой должна быть политика выселения, нужен ли вам срок действия ключей, должна ли это быть запись через кеш и т. Д.?
- Основываясь на этом анализе, нарисуйте диаграмму высокого уровня всей вашей системы.
Вещи которые должны быть
Вот некоторые ключевые вещи, которые должна иметь ваша диаграмма высокого уровня:
- Балансировщики нагрузки
- Услуги
- Базы данных и кеши
- Точки взаимодействия с пользователем
- Любые другие инструменты, такие как очередь сообщений, CDN и т. Д.
Прохождение дизайна
Когда у вас будет готовая диаграмма, просмотрите весь дизайн, по одному варианту использования за раз и объясните свой дизайн интервьюеру на очень высоком уровне. Поговорите о том, почему вы выбрали здесь конкретную базу данных и почему вы использовали определенный режим связи, такой как Sync / Async и т.д. Вам следует выяснить, какая стратегия репликации данных используется в ваших базах данных, например, вы бы использовали настройку Master-Slave или Multi Master и т. Д.
Если это звучит устрашающе, вы можете проверить Узнайте, как я обычно делаю пошаговое руководство по дизайну, в этом видео.
ВНИМАНИЕ. Не вдавайтесь в подробности, такие как API, схема БД и т. д., если только интервьюер не попросит об этом. Большинство людей теряются в разработке API-интерфейсов только для одной системы на этом этапе, а позже у него заканчивается время.
Brownie Points: в большинстве интервью нет FR и NFR по аналитике, но если ваш дизайн покрывает это или оставляет достаточно возможностей для аналитики, это значительно улучшает ваше решение. Попробуй это добавить. Например, вот это можно посмотреть.
Реализация
После того, как вы объясните весь процесс интервьюеру, спросите его, какой компонент он хочет подробно обсудить. Обычно люди не хотят вдаваться в подробности всей системы. Позвольте им решить, какой именно компонент они хотят изучить, а затем вы можете просмотреть детали реализации этой конкретной системы.
Здесь следует осветить следующие моменты:
- API. Вызов API, которые предоставляет эта система. Убедитесь, что вы используете здесь лучшие практики. Например, вместо GET API с URL-адресом типа GET / user / getUserbyUserId лучше использовать: GET / user / {id}
- Протоколы API. Вы можете указать, по каким протоколам вы используете API. Большинство людей выбирают REST API, но вы можете решить использовать что-то более эффективное, например Thrift, Protobuf и т. Д., В зависимости от ваших сценариев использования.
- События. Вы можете указать, какие события прослушивает эта конкретная служба, кто создает это событие, какие полезные данные поступают, какая обработка происходит при этом событии и т. д.
- Схема БД. Ознакомьтесь со схемой БД здесь. Вы также можете обсудить дискуссию о SQL и NoSQL или о том, почему вы выбрали конкретную базу данных, если вы не повторяли то же самое ранее, говоря о дизайне высокого уровня.
Если это SQL, поговорите о том, какие индексы вы Буду иметь и как вы оптимизируете свои запросы. В случае NoSQL убедитесь, что вы прошли гарантии согласованности, которые предоставляет БД, может ли это вызвать какие-либо проблемы и какие запросы вы будете запускать в этой БД. Ясно обозначьте ключи для хранилищ ключей и значений или ключи разделов для столбчатых хранилищ и т. Д.
Справиться с законом Мерфи
Это то, что большинство людей пропускает, но это одна из самых важных вещей, которую вы должны осветить, которая говорит о том, насколько устойчива ваша система. В реальном мире что-то ломается, и когда это происходит, вам нужно убедиться, что вы полностью контролируете свою систему.
Расскажите о том, как вы следите за системой. Какой у вас механизм оповещения? Каковы ваши KPI (ключевые показатели эффективности) и как вы их отслеживаете? Что происходит, когда что-то ломается, когда ваша служба выходит из строя, главный узел вашей БД выходит из строя или даже когда один из ваших центров обработки данных выходит из строя?
Опять же, если вы не делали этого раньше, посмотрите, как я это делаю, ближе к второй половине этого видео.
Это мой контрольный список, которому я обычно следую, когда пытаюсь разработать любую систему, будь то на собеседовании или в реальном мире.
Ну, это было для системного дизайна, если вы хотите посмотреть, как я смог взломать такие компании, как Google, Facebook, Amazon и т. Д., Взгляните на мою общую стратегию подготовки по адресу:
Надеюсь это поможет!
