Skip to main content

Процесс интервью

Вопросы по дизайну открыты и изначально намеренно расплывчаты. Такая расплывчатость имитирует реальность современного бизнеса.

Интервьюеры часто спрашивают об известной проблеме, например, о проектировании WhatsApp. Теперь настоящее приложение WhatsApp имеет множество функций, и включение всех из них в качестве требований для нашего клона WhatApp может быть неразумной идеей по следующим причинам:

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

Мы можем сказать интервьюеру, что есть много других вещей, которые делает настоящий WhatsApp, которые мы не собираемся включать в наш дизайн. Если у интервьюера есть какие-либо возражения, мы можем соответствующим образом изменить свой план действий.

img_6.png

  • Кандидат должен задать правильные вопросы, чтобы закрепить требования.
  • Кандидатам также необходимо определить масштаб проблемы, чтобы они могли попытаться решить ее в ограниченные сроки собеседования. Обычно SDI длятся около 35–40 минут.
  • Общение с интервьюером имеет решающее значение. Не стоит молча работать над дизайном. Вместо этого мы должны взаимодействовать с интервьюером, чтобы убедиться, что он понимает наш мыслительный процесс.

Проектирование на высоком уровне​

img_7.png

SDI часто включают вопросы, связанные с тем, как дизайн может развиваться с течением времени, когда какой-либо аспект системы увеличивается на определенный порядок величины, например, количество пользователей, количество запросов в секунду и т. д. В системном сообществе принято считать, что когда какой-либо аспект системы увеличивается в десять или более раз, тот же дизайн может не работать и может потребовать изменений.

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

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

Нет решений на века​

Все будет меняться, и со временем все будет ломаться по следующим причинам:

  • Не существует единственно правильного подхода или решения проблемы дизайна.
  • Многое основано на предположениях, которые мы делаем.

Распределенные системы дают нам ориентиры для зрелых принципов программного обеспечения. К ним относятся следующие:

  • Надежность (способность поддерживать работу во время кризиса) - Robustness
  • Масштабируемость - Scalability
  • Доступность - Availability
  • Производительность - Performance
  • Расширяемость - Extensibility
  • Отказоустойчивость (способность вернуться к нормальной работе в течение приемлемого периода времени после сбоя) - Resiliency

Такая терминология также выступает в качестве лингва-франка между интервьюером и кандидатом.

Кто получит это интервью?​

Каждый кандидат с опытом от 2 лет может получить это интервью.

Процесс подготовки​

На интервью​

Нужно понять реальную проблему​

Стоит избегать очень простых ответов в стиле - нам нужен клиент, сервер и база данных.

img_8.png

Нам нужно понять проблему дизайна и ее требования. Для этого мы можем надеть шляпу менеджера по продукту и расставить приоритеты основных функций, задавая интервьюеру уточняющие вопросы. Идея состоит в том, чтобы отправиться в путешествие с интервьюером о том, почему наш дизайн хорош. Эти интервью предназначены для оценки того, можем ли мы логически вывести систему из неопределенных требований.

Мы должны убедиться, что решаем правильную проблему. Часто бывает полезно разделить требования на две группы:

  • Требования, которые нужны клиентам напрямую, например, возможность отправлять сообщения друзьям в режиме, близком к реальному времени.
  • Требования, которые нужны косвенно, например, производительность службы обмена сообщениями не должна ухудшаться с ростом нагрузки пользователей.

Professionals call these functional and nonfunctional requirements.

Предоставить расчет данных​

Нам нужно ответить на вопросы

  • What’s the size of the data right now?
  • At what rate is the data expected to grow over time?
  • How will the data be consumed by other subsystems or end users?
  • Is the data read-heavy or write-heavy?
  • Do we need strict consistency of data, or will eventual consistency work?
  • What’s the durability target of the data?
  • What privacy and regulatory requirements do we require for storing or transmitting user data?

Перейти к обсуждению компонентов​

img_9.png

На каком-то уровне наша работа может восприниматься как выяснение того, какие компоненты мы будем использовать, где они будут размещены и как они будут взаимодействовать друг с другом.
Примером может служить тип базы данных — будет ли работать обычная база данных или нам следует использовать базу данных NoSQL?
Могут быть случаи, когда у нас есть веские аргументы в пользу использования баз данных NoSQL, но наш интервьюер может настаивать на использовании традиционной базы данных. Что нам следует делать в таком случае?

Нет верного решения​

Вот некоторые из причин, по которым существует такое разнообразие в проектных решениях:

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

Чего не надо делать​

Вот несколько вещей, которых следует избегать на собеседовании по системному проектированию

  • Не пишите код на собеседовании по системному проектированию.
  • Не начинайте разработку без плана.
  • Не работайте молча.
  • Не описывайте цифры без причины. Мы должны это обрамить.
  • Если мы чего-то не знаем, мы не скрываем это и не притворяемся, что знаем.

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

Еще раз про шаги​

  • Determine system requirements and constraints
  • Recognize components
  • Generate design
  • Discuss trade-offs and improve iteratively
  • Identify shortcomings in the initial design

Here are some additional tips you can apply during your system design interview:

  • Communicate: Make sure to articulate your thought process during the interview. Interviewers value your ability to ask insightful questions and your openness to feedback.
  • Manage your time: Given the limited time in system design interviews, prioritize the broader design aspects over diving too deep into one component.
  • Strategically tackle unseen design problems: Employ a structured approach to navigate through unfamiliar problems. The RESHADED approach mentioned in the course can be particularly helpful.
  • Ask questions: Proactively asking questions can help uncover hidden requirements and constraints, allowing you to refine your design further.

Прежде чем идти дальше​

Задавая себе правильные вопросы, кандидаты могут продумывать сложные и неоднозначные ситуации.

  • Изучите, как работают популярные приложения на высоком уровне, например, Instagram, Twitter и т. д.
  • Начните понимать и спрашивать, почему один компонент был использован вместо другого, например, Firebase вместо SQL.
  • Создавайте серьезные сторонние проекты. Начните с простого продукта, а затем улучшайте и совершенствуйте его.
  • Создайте систему с нуля и ознакомьтесь со всеми процессами и деталями ее построения.
  • Мы можем клонировать популярное приложение без обучающих программ.

Проектирование систем имеет дело с компонентами более высокого уровня, и нам следует избегать углублений.
Нам следует меньше фокусироваться на механике и больше на компромиссах.

Например, обсуждение того, использовать ли библиотеку Room вместо чистого SQLite, бесполезно, поскольку библиотека Room — это просто оболочка вокруг SQLite. Лучше обсудить использование традиционных баз данных, таких как MySQL, или использование хранилищ NoSQL, таких как MongoDB. Это второе обсуждение поможет нам определить компромиссы между ними.
Начнем с высокоуровневых вещей, потому что низкоуровневые детали появятся автоматически.

The RESHADED Approach for System Design​

Введение​

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

Преимущества RESHADED​

Прежде чем мы рассмотрим каждый элемент в RESHADED, давайте обсудим преимущества нашего подхода в целом. Некоторые из ключевых преимуществ этого подхода включают:

  • RESHADED помогает нам запомнить ключевые шаги для решения каждой задачи проектирования. Это означает, что в любой момент времени у нас всегда будет определен следующий шаг.

  • Решение, которое мы разрабатываем, будет содержать все основные элементы, необходимые для решения любой задачи проектирования. Более того, решение, предложенное через подход RESHADED, будет систематическим и продуманным.

img_243.png

Изучение RESHADED​

Ниже мы описываем шаги, которые выполняем на каждом этапе RESHADED:

  • Requirements (Требования): На этом этапе мы собираем все требования задачи проектирования и определяем её объем. Требования включают понимание того, что представляет собой сервис, как он работает и какие основные функции он выполняет. Наша цель на этом этапе — собрать функциональные и нефункциональные требования к сервису, который мы собираемся спроектировать.

  • Estimation (Оценка): Как следует из названия, этот этап включает оценку ресурсов, необходимых для предоставления сервиса определенному количеству пользователей. Под ресурсами мы понимаем аппаратные или инфраструктурные ресурсы.

    Примеры вопросов по оценке:

    • Сколько серверов потребуется для предоставления бесперебойных услуг 500 миллионам активных пользователей в день?
    • Сколько памяти потребуется, если нужно хранить 125 миллионов твитов в день, и 20% твитов содержат медиафайлы?

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

  • Storage Schema (Схема хранения, опционально): Этот этап включает в себя описание нашей модели данных, то есть мы определяем, какие таблицы нам нужны и какие поля будут в каждой таблице. Однако это опциональный шаг, и мы можем не применять его в каждой задаче проектирования.

  • High-level Design (Высокоуровневое проектирование): Этот этап включает идентификацию основных компонентов и строительных блоков, которые мы будем использовать для проектирования нашей системы. Мы делаем это, опираясь на наши функциональные и нефункциональные требования.

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

  • API Design (Проектирование API): Цель на этом этапе — разработать интерфейсы для нашего сервиса. С помощью этих интерфейсов пользователи могут вызывать различные услуги внутри нашей системы. Эти интерфейсы представлены в виде API вызовов и обычно являются переводом наших функциональных требований.

  • Detailed Design (Детализированное проектирование): Детализированное проектирование начинается с выявления ограничений высокоуровневого проектирования. Мы используем эти ограничения для развития нашего дизайна. На этом этапе мы завершаем проектирование, указав все компоненты и строительные блоки, которые мы будем использовать.

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

  • Evaluation (Оценка): Этот этап измеряет эффективность нашего решения. Другими словами, мы обосновываем, как наш дизайн удовлетворяет функциональные и нефункциональные требования.

    Мы обсуждаем различные компромиссы, на которые мы пошли в нашем решении, а также определяем возможности для улучшения.

  • Distinctive Component/Feature (Уникальный компонент/функция): В начале этого урока мы обсуждали, что универсального решения не существует. Этот этап направлен на выявление уникального аспекта для каждой задачи проектирования и его обсуждение. Например, в задаче проектирования Uber уникальной функцией является сервис оплаты и обнаружение мошенничества. В отличие от этого, в Google Docs уникальной функцией является управление конкурентностью, которое необходимо, когда разные пользователи хотят одновременно редактировать один и тот же раздел документа.