Собеседования по системному дизайну являются важной частью технического собеседования, особенно для должностей старших разработчиков программного обеспечения. Эти собеседования оценивают способность кандидата проектировать крупномасштабные распределенные системы, необходимые для создания надежных и масштабируемых приложений. Тем не менее, пройти собеседование по проектированию системы может быть непросто, особенно если вы не знакомы с процессом или техническими концепциями.
В этой статье я поделюсь шаблоном, которым я следовал, чтобы блестяще проводить интервью по проектированию систем с такими технологическими гигантами, как Flipkart и Phonepe и другими. Эти шаги основаны на моем личном опыте и исследованиях. Являетесь ли вы опытным инженером или только начинаете свою карьеру, эти советы и стратегии помогут вам чувствовать себя уверенно и подготовиться к следующему собеседованию по проектированию системы.
Следуя этому шаблону, на собеседовании можно разработать любую систему:
Уточнить проблему
Убедитесь, что вы поняли формулировку проблемы, и при необходимости задайте уточняющие вопросы.
Соберите требования
Доработать функциональные и нефункциональные требования.
Функциональный
Функциональные требования — это функциональные возможности, которые система или приложение может предоставить пользователю. Пример: в Твиттере пользователь может подписаться на другого пользователя, твитнуть, лайкнуть твит, ретвитнуть чужой твит и поделиться твитом (сосредоточьтесь на основных функциях и не вникайте в сложные функции твиттера).
Нефункциональный
Для любой распределенной системы необходимо учитывать следующие основные концепции:
- Высокая доступность: большинство систем должны быть высокодоступными.
- Непротиворечивость: Системы с высокой доступностью будут иметь конечную согласованность. Любая банковская система отдает предпочтение согласованности, а не доступности, поскольку расхождений в данных (балансе счета) быть не может.
- Надежность: без потери пользовательских данных.
- Задержка: время отклика на действие пользователя, такое как загрузка веб-страницы, отметка «Нравится» публикации и т. д.
Завершить в масштабе приложения.
Определите ожидаемый масштаб, в котором должно работать наше приложение. Это может повлиять на решения по дизайну и хранению данных, которые мы будем принимать.
Проверьте типы пользователей для приложения (необязательно)
Определите актеров/пользователей для нашего приложения, таких как Клиенты/Администраторы/Администраторы клиентов.
Доработайте API, чтобы лучше понять шаблоны запросов.
Определите ввод и вывод системы (с помощью API), это дает ясность в отношении того, как отдельные компоненты должны взаимодействовать друг с другом.
Архитектура дизайна
Определите ключевые компоненты или модули, из которых будет состоять система.
Создайте высокоуровневую архитектуру системы, включая то, как компоненты будут взаимодействовать друг с другом. Сначала начните с очень простого дизайна, а затем расширяйте его.
- Расширение дизайна — Создание конкретных компонентов:
- Изоляция сервисов — для упрощения масштабирования и контроля трафика
- Репликация сервисов и баз данных — упоминание о единой точке отказа — Видео
- Балансировщик нагрузки — Сторона приложения и сторона базы данных, если необходимо — Видео, Блог
- Очереди сообщений — тесная и слабая связь / синхронная и асинхронная связь — чтение очередей сообщений, преимущества MQ
- Разделение данных — на основе местоположения, на основе идентификатора пользователя — видео, блог
- Сеть доставки контента — чтобы избежать обращения к основному серверу (уменьшает задержку). Видео, ИнтервьюВопросы
- Кэш — Распределенный кеш и кеш на стороне клиента (для более быстрого чтения) — Видео, Блог, Букварь
Определите структуру базы данных для микросервисов.
Дизайн базы данных для микросервисов.
- Отдельная БД для каждого сервиса
- Общая БД среди всех сервисов
Важные шаблоны базы данных, которые следует помнить:
Шаблон SAGA - › Поддерживайте свойства транзакций в микросервисах, каждый из которых имеет отдельную БД.
Шаблон CQRS -> Выполнение объединений в микросервисах, каждый из которых имеет отдельную БД.
Определите тип для каждой базы данных.
После обсуждения данных и действий, которые пользователь может выполнять для взаимодействия с системой. Следующим шагом будет разговор о том, какой тип БД вы будете использовать, и о ваших причинах его использования.
Оценка хранилища
- На основе модальности данных: приблизительная оценка того, сколько данных необходимо хранить — чтобы знать, какой тип базы данных можно использовать и файловое хранилище для хранения изображений/видео.
- Количество запросов к сервису — Чтобы знать, как масштабировать сервисы. Службу с большим количеством операций чтения можно масштабировать для обработки большого трафика запросов.
- Read Write ratio — Определяет, является ли система интенсивно читаемой или нет.
Моменты, которые следует учитывать при выборе типа базы данных:
1. Структура данных (или неструктурированных данных)/схема.
2. Шаблоны запросов.
3. Необходимое масштабирование.
Выбор базы данных:
- Структурированные данные:
— Нужна ACID -> РСУБД (MySQL, Oracle, PostgreSQL) - Неструктурированные данные:
— множество типов данных (столбцы) и множество запросов (сложные запросы) -> база данных документов (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
Масштабирование нашего приложения
Подумайте, как система будет масштабироваться с точки зрения трафика и роста числа пользователей.
- Один сервер
- Разделение сервера приложений и сервера БД
- Балансировщик нагрузки + несколько серверов приложений
- Репликация базы данных
- Кэш
- CDN (решение проблемы с задержкой для удаленных пользователей)
- Несколько центров обработки данных с перекрестной репликацией
- Очередь сообщений
- Масштабирование базы данных (путем сегментирования)
Для тяжелых систем чтения создайте отдельную службу для чтения и записи.
Дополнительные компоненты (опционально)
Эти компоненты можно добавить в дизайн, если у вас осталось время на собеседование. Знание этих компонентов поможет вам ответить на любые дополнительные вопросы. Как правило, компонентов, упомянутых выше, будет достаточно, и они отнимут у вас большую часть времени на собеседовании.
- Шифрование (сообщения) — для служб обмена сообщениями для защиты данных.
- Сервис аналитики — для анализа запросов и пользовательских данных
- Сервис машинного обучения — рейтинг рекомендаций/новостных лент (если требуется вариант использования (Netflix), добавьте его к базовым компонентам) — расскажите о данных, необходимых для вашей модели рекомендаций/ранжирования.
- Шлюз API — видео, подробные микросервисы и шлюз API.
- Обнаружение сервисов — для динамической идентификации микросервисов.
Совет: чем больше вопросов вы зададите интервьюеру, тем больше информации вы получите от интервьюера и тем лучше будет ваш дизайн.
В основном подумайте о том, как вы можете сделать свою систему отказоустойчивой (система должна работать постоянно) и масштабируемой (чтобы справляться с растущим объемом трафика). Подумайте о узких местах и о том, как их можно решить.
Постарайтесь пропустить лишнюю информацию в интересах экономии времени.
Не забывайте думать вслух и объяснять ход своих мыслей по мере прохождения каждого из этих шагов.
Я надеюсь, что эти советы и стратегии помогут вам успешно пройти следующее собеседование по проектированию систем. Если вам понравилось читать эту статью и вы хотите получать больше полезного контента, обязательно подпишитесь на меня. Я поделюсь своими мыслями и советами по собеседованиям по разработке программного обеспечения, развитию карьеры и технологиям в целом.
Не забудьте похлопать в ладоши и поделиться этой статьей с друзьями и коллегами, которым она может быть полезна. Удачи! Спасибо за прочтение!