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

В этой статье я поделюсь шаблоном, которым я следовал, чтобы блестяще проводить интервью по проектированию систем с такими технологическими гигантами, как Flipkart и Phonepe и другими. Эти шаги основаны на моем личном опыте и исследованиях. Являетесь ли вы опытным инженером или только начинаете свою карьеру, эти советы и стратегии помогут вам чувствовать себя уверенно и подготовиться к следующему собеседованию по проектированию системы.

Следуя этому шаблону, на собеседовании можно разработать любую систему:

Уточнить проблему

Убедитесь, что вы поняли формулировку проблемы, и при необходимости задайте уточняющие вопросы.

Соберите требования

Доработать функциональные и нефункциональные требования.

Функциональный

Функциональные требования — это функциональные возможности, которые система или приложение может предоставить пользователю. Пример: в Твиттере пользователь может подписаться на другого пользователя, твитнуть, лайкнуть твит, ретвитнуть чужой твит и поделиться твитом (сосредоточьтесь на основных функциях и не вникайте в сложные функции твиттера).

Нефункциональный

Для любой распределенной системы необходимо учитывать следующие основные концепции:

  • Высокая доступность: большинство систем должны быть высокодоступными.
  • Непротиворечивость: Системы с высокой доступностью будут иметь конечную согласованность. Любая банковская система отдает предпочтение согласованности, а не доступности, поскольку расхождений в данных (балансе счета) быть не может.
  • Надежность: без потери пользовательских данных.
  • Задержка: время отклика на действие пользователя, такое как загрузка веб-страницы, отметка «Нравится» публикации и т. д.

Завершить в масштабе приложения.

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

Проверьте типы пользователей для приложения (необязательно)

Определите актеров/пользователей для нашего приложения, таких как Клиенты/Администраторы/Администраторы клиентов.

Доработайте API, чтобы лучше понять шаблоны запросов.

Определите ввод и вывод системы (с помощью API), это дает ясность в отношении того, как отдельные компоненты должны взаимодействовать друг с другом.

Архитектура дизайна

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

  • Расширение дизайна — Создание конкретных компонентов:
  • Изоляция сервисов — для упрощения масштабирования и контроля трафика
  • Репликация сервисов и баз данных — упоминание о единой точке отказа — Видео
  • Балансировщик нагрузки — Сторона приложения и сторона базы данных, если необходимо — Видео, Блог
  • Очереди сообщений — тесная и слабая связь / синхронная и асинхронная связь — чтение очередей сообщений, преимущества MQ
  • Разделение данных — на основе местоположения, на основе идентификатора пользователя — видео, блог
  • Сеть доставки контента — чтобы избежать обращения к основному серверу (уменьшает задержку). Видео, ИнтервьюВопросы
  • Кэш — Распределенный кеш и кеш на стороне клиента (для более быстрого чтения) — Видео, Блог, Букварь

Определите структуру базы данных для микросервисов.

Дизайн базы данных для микросервисов.

  1. Отдельная БД для каждого сервиса
  2. Общая БД среди всех сервисов

Важные шаблоны базы данных, которые следует помнить:

Шаблон SAGA - › Поддерживайте свойства транзакций в микросервисах, каждый из которых имеет отдельную БД.

Шаблон CQRS -> Выполнение объединений в микросервисах, каждый из которых имеет отдельную БД.

Определите тип для каждой базы данных.

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

Оценка хранилища

  • На основе модальности данных: приблизительная оценка того, сколько данных необходимо хранить — чтобы знать, какой тип базы данных можно использовать и файловое хранилище для хранения изображений/видео.
  • Количество запросов к сервису — Чтобы знать, как масштабировать сервисы. Службу с большим количеством операций чтения можно масштабировать для обработки большого трафика запросов.
  • Read Write ratio — Определяет, является ли система интенсивно читаемой или нет.

Моменты, которые следует учитывать при выборе типа базы данных:

1. Структура данных (или неструктурированных данных)/схема.
2. Шаблоны запросов.
3. Необходимое масштабирование.

Выбор базы данных:

  1. Структурированные данные:
    — Нужна ACID -> РСУБД (MySQL, Oracle, PostgreSQL)
  2. Неструктурированные данные:
    — множество типов данных (столбцы) и множество запросов (сложные запросы) -> база данных документов (MongoDB, Couchbase)
    — постоянно увеличивающиеся данные (экспоненциально увеличивающиеся данные) и конечные запросы ( Меньше запросов) -> Столбчатая БД (Cassandra, HBase)

Другие варианты хранения

Для кэша – Redis
Для хранилища BLOB-объектов – › S3 + CDN
Система текстового поиска – › Elastic Search или Solr
Append Only Mode Write, Bulk Read on time range – › TimeSeries DB (Grafana /Prometheus)
Хранилище данных -> Hadoop или RedShift

Масштабирование нашего приложения

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

  1. Один сервер
  2. Разделение сервера приложений и сервера БД
  3. Балансировщик нагрузки + несколько серверов приложений
  4. Репликация базы данных
  5. Кэш
  6. CDN (решение проблемы с задержкой для удаленных пользователей)
  7. Несколько центров обработки данных с перекрестной репликацией
  8. Очередь сообщений
  9. Масштабирование базы данных (путем сегментирования)

Для тяжелых систем чтения создайте отдельную службу для чтения и записи.

Дополнительные компоненты (опционально)

Эти компоненты можно добавить в дизайн, если у вас осталось время на собеседование. Знание этих компонентов поможет вам ответить на любые дополнительные вопросы. Как правило, компонентов, упомянутых выше, будет достаточно, и они отнимут у вас большую часть времени на собеседовании.

  • Шифрование (сообщения) — для служб обмена сообщениями для защиты данных.
  • Сервис аналитики — для анализа запросов и пользовательских данных
  • Сервис машинного обучения — рейтинг рекомендаций/новостных лент (если требуется вариант использования (Netflix), добавьте его к базовым компонентам) — расскажите о данных, необходимых для вашей модели рекомендаций/ранжирования.
  • Шлюз API — видео, подробные микросервисы и шлюз API.
  • Обнаружение сервисов — для динамической идентификации микросервисов.

Совет: чем больше вопросов вы зададите интервьюеру, тем больше информации вы получите от интервьюера и тем лучше будет ваш дизайн.

В основном подумайте о том, как вы можете сделать свою систему отказоустойчивой (система должна работать постоянно) и масштабируемой (чтобы справляться с растущим объемом трафика). Подумайте о узких местах и ​​о том, как их можно решить.

Постарайтесь пропустить лишнюю информацию в интересах экономии времени.

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

Я надеюсь, что эти советы и стратегии помогут вам успешно пройти следующее собеседование по проектированию систем. Если вам понравилось читать эту статью и вы хотите получать больше полезного контента, обязательно подпишитесь на меня. Я поделюсь своими мыслями и советами по собеседованиям по разработке программного обеспечения, развитию карьеры и технологиям в целом.
Не забудьте похлопать в ладоши и поделиться этой статьей с друзьями и коллегами, которым она может быть полезна. Удачи! Спасибо за прочтение!