В зависимости от уровня старшинства должности некоторые компании могут принять решение пропустить это собеседование. Более старшие инженеры обязательно столкнутся с этими интервью. Для крупных компаний, таких как Google и Microsoft, эти собеседования обязательны.
Так что же такое системный дизайн?

Определение: проектирование систем — это процесс определения элементов системы, таких как модули, архитектура, компоненты и их интерфейсы и данные для системы, на основе заданных требований. Это процесс определения, разработки и проектирования систем, которые удовлетворяют конкретные потребности и требования бизнеса или организации.

Представьте, что вы входите в комнату для интервью, и вас спрашивают: «Как бы вы разработали TikTok?». С чего бы вы начали? Я могу сказать вам, с чего не следует начинать. НЕ ДУМАЙТЕ О ФУНКЦИОНАЛАХ TIK-TOK И ПЫТАЙТЕСЬ ПЕРЕВЕСТИ ИХ В КОД.

На собеседованиях по системному проектированию ваш интервьюер хочет знать, можете ли вы разрабатывать масштабируемые приложения (Проектировать, а не писать код) и делать это так, чтобы соответствовать требованиям клиента. Какой тип системы вы проектируете? Является ли это системой финансовых транзакций, которая ДОЛЖНА отдавать предпочтение параллелизму данных, а не доступности? (поговорите ТЕОРЕМА CAP).
Сколько одновременных пользователей ожидается в приложении в самые загруженные дни?
Каково географическое распределение этих пользователей? Знаете ли вы, что физическое расстояние между серверами и пользователями влияет на задержку?

Примечание. Проектирование систем — очень широкая тема, и я буду писать по максимально возможному количеству тем из этой темы. А пока давайте продолжим наше воображение.

При разработке Tik-Tok необходимо учитывать множество факторов:

  1. продолжительность видео, сколько пользователей смотрят видео и сколько пользователей загружают видео (соотношение чтения/записи)
  2. Какие типы баз данных использовать (существует как минимум пять других типов баз данных, кроме баз данных документов и реляционных баз данных)
  3. Какие алгоритмы использовать
  4. Как пользователи аутентифицируются
  5. Как реализовать поиск аккаунта
  6. Как отслеживать популярные видео (видео в Нигерии может не быть в тренде в Австралии)

Этот список можно продолжать и продолжать. На собеседовании по системному дизайну вам дается максимум около часа. Уверен, вы понимаете, насколько это проблема.
Столько всего нужно обсудить, а времени так мало. Итак, как вы это делаете?

Задавайте вопросы для уточнения.

вторая величайшая ошибка, помимо написания кода на собеседовании по проектированию систем, — это не задавать вопросы. Если интервьюер хочет, чтобы вы сосредоточились на аутентификации, а вы говорите о базах данных в течение 30 минут, это неправильно.
Видите ли, задавание вопросов позволит интервьюеру подтолкнуть вас в том направлении, в котором они хотят, чтобы вы двигались. Вы можете сказать что-то вроде: «Это кажется такой большой системой. Есть ли какие-то конкретные области, на которых вы хотели бы, чтобы я сосредоточился?». Задавайте такие вопросы, как:

  • Сколько пользователей мы ожидаем в нашей системе?
  • Какой тип данных они будут записывать в наши базы данных?
  • Какой объем данных разрешено хранить пользователям за определенный период?

Чтобы ответить на эти вопросы, интервью может сказать вам: «Мы хотим, чтобы у Tik-Tok было 50 миллионов одновременных пользователей, и пользователи могли загружать видео размером 12 МБ один раз в день, а соотношение чтения/записи составляло 4:1». Теперь вы знаете, что вам нужно ежедневно хранить 12 МБ * 10 миллионов (120 терабайт) данных и что пользователям необходимо ежедневно читать не менее 480 терабайт (120 терабайт * 4) данных.
Из одних только этих вопросов вы теперь знаете, что это система с большим количеством операций чтения. Вы также понимаете, что будете хранить много видео.

Знайте, что делать с имеющейся у вас информацией.

Вы задавали вопросы и получали ответы. Теперь подумайте, как эти ответы повлияют на ваш дизайн.
Вы будете хранить много видео. Для этого вам понадобится специализированная база данных. Реляционные базы данных (например, Postgres) и нереляционные базы данных (например, базы данных документов, такие как MongoDB) не могут эффективно хранить видео. Вам нужна база данных хранилища объектов, такая как AWS S3.
Если вы попытаетесь одновременно прочитать 50 миллионов видео с одного сервера, вполне вероятно, что сервер станет медленным или в конечном итоге выйдет из строя. Это означает, что вам нужно более одного сервера. По сути, вам нужно масштабировать серверы (горизонтально всегда лучше).
Теперь у вас есть несколько реплик одного и того же сервера. Как вы можете сопоставить запрос пользователя с конкретным сервером? Вам понадобится что-то под названием балансировщик нагрузки.
Что, если ваш интервьюер скажет, что пользователи разбросаны по всему миру? Это переменная, которую мы раньше не рассматривали. Теперь нам нужно несколько серверов в разных странах/континентах. Можем ли мы использовать сеть доставки контента (CDN) для распространения этих видео?
Теперь, когда у нас есть люди в разных местах, мы можем собирать популярные видео для каждого места и использовать кеш для их хранения для более быстрого доступа.

Некоторые и советы

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

  1. знать и понимать модные слова. Узнайте, что такое балансировщики нагрузки и для чего они используются. Прочтите о задержке, доступности, параллелизме и разделении баз данных.
  2. Узнайте о различных типах баз данных:
    - Реляционные базы данных
    - Базы данных документов
    - Базы данных временных рядов
    - Базы данных кэширования
    - Базы данных поиска
    - Объекты базы данных хранилища
     — столбцовые базы данных
     – графовые базы данных и т. д.
  3. Узнайте, какие экземпляры использовать эти специализированные базы данных. ЗНАТЬ ПРИМЕРЫ ЭТИХ БАЗ ДАННЫХ.
  4. Узнайте, как эти базы данных можно комбинировать с другими технологиями для создания эффективных решений. Хорошим примером этого является знание того, что хранилище объектов (например, AWS) можно комбинировать с CDN (например, Cloudfare), чтобы обеспечить легкодоступное и легкодоступное хранилище файлов.
  5. Не забудьте упомянуть, как внешнее приложение взаимодействует с сервером. Эту деталь легко пропустить. Не зацикливайтесь на этом, а упоминайте. Эта ошибка и несколько других стоили мне одной из самых больших возможностей трудоустройства в моей карьере.
  6. Практическое правило:
    - Если вы строите систему с большим количеством операций чтения, вы всегда можете добавить кеш-базу данных (например, Redis) где-нибудь, чтобы ускорить доступ к данным.
    – При создании систем с большим количеством операций чтения, в которых параллелизм предпочтительнее доступности, всегда полезно иметь несколько реплик ваших записываемых баз данных, доступных только для чтения.
    – В транзакционных системах параллелизм имеет приоритет над доступностью. Вы не хотите иметь различные банковские записи клиентов. В системе электронной коммерции покупка товаров должна осуществляться в порядке очереди. Доступный запас продуктов после каждой покупки должен быть одинаковым по всей системе.
    - Если на создание чего-то уходит слишком много времени или это отвлекает внимание от основного продукта, это всегда можно передать на аутсорсинг. В нашем примере с Tik-Tok мы всегда можем использовать доступные CDN для распространения контента, а не иметь дорогостоящие физические серверы по всему миру. сегментировать базу данных — масштабировать ее горизонтально, используя разумный индекс.
    — Вы вряд ли ошибетесь, если введете несколько реплик очень загруженных серверов и внедрите балансировщик нагрузки.
    — На сегодняшний день (по крайней мере, до квантового становится широко распространенным), отправка конфиденциальной информации должна выполняться через HTTP.
    - Если у вас есть задачи, выполнение которых запланировано на более поздний срок, вы всегда можете запустить задание в своей базе данных или использовать очередь сообщений ( например, Кролик MQ).
  7. Ваш дизайн ДОЛЖЕН быть расширяемым. В нашем примере с Tik-Tok мы внесли огромные изменения в дизайн, просто предполагая, что наши пользователи будут распределены по всему миру. Но поскольку наш дизайн был расширяемым, он не сломался. Это свидетельствует о хорошем дизайне. Новые компоненты также должны легко подключаться.
  8. Говорите четко и уверенно. Чем лучше вы разбираетесь, тем увереннее вы будете говорить. Проведите исследование.
  9. Дайте интервьюеру возможность задавать вопросы. Слушайте и учитесь.
  10. Наконец, проектирование систем — очень обширная тема. Я буду подробно обсуждать многие из этих тем в следующих статьях. Если вы нашли это полезным, хлопайте в ладоши и делитесь.

Не стесняйтесь обращаться к Twitter и LinkedIn и дайте мне знать, о каких концепциях вы хотели бы, чтобы я написал.