Советы по прохождению собеседования по проектированию систем в технической компании.
Большинство технологических компаний проводят этап проектирования системы как часть процесса собеседования. Кандидатов обычно просят разработать масштабируемую систему, такую как Facebook NewsFeed, Instagram-истории, чат WhatsApp, систему CI / CD и т. Д.
В Интернете есть много ресурсов для подготовки к собеседованию по системному дизайну. Изобилие ресурсов может стать непосильным для любого разработчика. Однако есть общие закономерности, наблюдаемые в вопросах, задаваемых техническими компаниями. Наличие кристально ясного представления о концепциях и основах системного проектирования помогает любому кандидату добиться успеха.
В этой статье я собираюсь разработать систематическую и организованную стратегию, чтобы помочь любому пройти собеседование. Попутно я также проиллюстрирую различные задаваемые вопросы и подходы к их решению.
Зачем нужны собеседования по проектированию систем?
Сегодня большинство технологических компаний инвестируют в создание масштабируемых высокопроизводительных систем. Следовательно, инженеру очень важно обладать потрясающими дизайнерскими навыками.
Интервью по проектированию системы намеренно открыты и неоднозначны. Это дает интервьюеру возможность оценить кандидата по разным параметрам. Помимо навыков проектирования, это также помогает интервьюеру оценить общий мыслительный процесс кандидата, его мышление, знания алгоритмов и коммуникативные навыки.
Стратегия высокого уровня
Я следую следующему пятиэтапному подходу на собеседовании по проектированию системы:
- Требования и уточняющие вопросы
- Оценка емкости
- Цели дизайна
- Дизайн и алгоритмы API
- База данных, дизайн кэша и сегментирование
Мы подробно рассмотрим каждый из вышеперечисленных шагов.
Требования и уточняющие вопросы
Когда перед нами возникает такая проблема, как разработка серверной системы для Uber, нам приходят в голову тысячи функций. Фактически, такие системы, как Uber, Facebook и т. Д., Развивались за годы инженерных усилий и тщательности. Спроектировать крупномасштабную систему за 45–60 минут непросто.
Поскольку мы не можем спроектировать все функции крупномасштабной системы из-за ограниченного времени, важно сузить масштаб проблемы. Требования можно разделить на функциональные и нефункциональные. Вы можете подумать обо всех простых функциях, которые можно создать на доске или листе бумаги во время собеседования.
Например: в случае бэкэнда «Проектирование» для Uber вы можете перечислить следующие требования по объему: -
- Гонщики должны иметь возможность бронировать и отменять поездку.
- Система должна соответствовать гонщику с водителем
- Водители могут отменить назначенную поездку
- Водители и гонщики могут оценивать друг друга после поездки.
- Водители могут платить водителю, используя несколько способов оплаты.
Кроме того, обязательно нужно задавать уточняющие вопросы. Вы должны понимать, кто является пользователями системы, как они собираются с ней взаимодействовать, каковы будут шаблоны использования. Эти вопросы помогут вам определить узкие места, устранить дублирование и масштабировать систему в целом.
Оценка емкости
При уточнении требований к системе следует задать следующий вопрос: сколько пользователей собираются использовать нашу систему? Это важный вопрос, поскольку позже он поможет ответить на многие узкие места в дизайне.
Приблизительное представление об активных пользователях поможет вам оценить, сколько запросов получит ваша система, а также вы сможете вычислить необходимое хранилище данных. Кроме того, вы можете понять, является ли система тяжелой для чтения или для записи. Это повлияет на ваш выбор хранилища данных (SQL против NoSQL) и потребность в уровне кэширования в вашем приложении.
Допустим, вы разрабатываете такую систему, как Twitter. В этом случае вы можете сделать следующие оценки:
- 200 млн активных пользователей с 600 млн твитов в день
- У каждого пользователя в среднем 100 подписчиков
- Твит ретвитился в среднем не менее 10 раз.
- Человек, публикующий 1 медиафайл на каждые 10 твитов.
Вычислив оценки, вы получите ясность в отношении степени горизонтального масштабирования или количества серверов, необходимых в системе. Более того, использование приблизительной оценки объема данных, которые необходимо сохранить, поможет вам соответствующим образом спланировать серверы баз данных.
Цели дизайна
Одним из основных требований к любой системе является задержка и пропускная способность. Задержка - это время, необходимое для обработки данного запроса от клиента. В то время как под пропускной способностью понимается количество запросов, которые могут быть обработаны в течение заданного интервала времени.
Для высокопроизводительной системы важно иметь минимальную задержку при максимальной пропускной способности. Если вы разрабатываете веб-сайт покупок, который долго загружается, это приводит к неудовлетворительному взаимодействию с пользователем. Кроме того, в день распродажи в черную пятницу производительность вашей системы не должна снижаться из-за увеличения нагрузки.
Вторая цель дизайна - выбрать между доступностью и согласованностью. Согласно теореме CAP, вы можете иметь систему CP или AP, чтобы выдерживать сбои в сетях. Выбор между доступностью и согласованностью зависит от того, какой тип системы разрабатывается.
Если у вас есть банковская система, которая напрямую работает с деньгами пользователей, согласованность приобретает первостепенное значение. Принимая во внимание, что если вы разрабатываете канал Facebook, это нормально, если вы пропустите обновление статуса на странице или от друга.
Дизайн и алгоритмы API
Для каждого из требований, которые входят в объем проблемы, необходимо набросать основные API-интерфейсы, которые будет предоставлять серверная система. Кандидат может упомянуть запросы, ответы, коды состояния, используемый HTTP-метод и т. Д. В зависимости от проблемы, один раз может обсудить, использовать ли REST, GraphQL или GRPC для разработки API.
Далее вы можете перейти к рисованию высокоуровневых компонентов, которые будут использоваться в системе. Хорошо начать с компонентов, ориентированных на клиента, например, шлюза API, балансировщиков нагрузки. Вы можете поговорить о том, какие стратегии можно использовать в балансировщиках нагрузки для равномерного распределения нагрузки между серверами приложений.
Если вас просят разработать такую систему, как Youtube, Netflix или Instagram, вы также можете поговорить о CDN (сети доставки контента), которая облегчает обслуживание статических изображений или видеофайлов.
Для каждого API вам нужно будет увидеть, нужно ли реализовать алгоритм на стороне сервера или это простой CRUD API. Например: - При разработке твиттера, чтобы получать новостную ленту, вам нужно придумать алгоритм новостной ленты. Если пользователь следует за другим пользователем, это будет простой CRUD API.
База данных, дизайн кеша и сегментирование
Оценка емкости даст вам представление о том, сколько данных необходимо обработать вашей системе. Более того, вы должны иметь четкое представление об объектах, участвующих в моделировании данных, и отношениях между ними. Вам нужно выяснить, являются ли ваши данные структурированными или неструктурированными, и нужна ли им гибкость схемы или нет. Ответы на вышеуказанный вопрос повлияют на ваш выбор использования базы данных SQL или NoSQL.
Большинство систем - это системы с большим количеством операций чтения. Следовательно, вы можете ускорить все запросы чтения вашей базы данных, создав индекс для столбца или набора столбцов в зависимости от шаблонов доступа. У вас может быть архитектура «ведущий-ведомый», в которой записи выполняются на ведущем устройстве, а чтение - на ведомом. Это изолирует чтение от записи и, таким образом, улучшит производительность системы.
Чтение из базы данных приводит к операции ввода-вывода, выполнение которой требует больших вычислительных ресурсов. Вы можете добавить уровень кэширования между приложением и базой данных, чтобы минимизировать дисковый ввод-вывод. Это еще больше повысит производительность системы.
При добавлении кеша вам нужно будет выбирать между стратегиями вытеснения кеша, а также шаблонами кэширования, такими как сквозная запись, обратная запись, кэш в сторону и т. Д.
Если вы проектируете систему для миллионов пользователей, данные не поместятся на одном сервере базы данных. Следовательно, важно распределить данные между несколькими серверами баз данных. Это называется разделением данных. Интервьюер может спросить вас о различных стратегиях разделения данных, которые вы можете использовать для распределения данных, и обсудить компромиссы при использовании каждой из них.
Накопление знаний в области проектирования систем требует много времени, опыта и усилий. Вы можете ссылаться на интересные технические блоги, где компании хорошо сформулировали способ решения сложных проблем.
Кроме того, вы можете попробовать решить как можно больше проблем с дизайном. Такие форумы, как LeetCode и Carrer cup, помогут вам связаться с инженерами-единомышленниками, и вы даже можете столкнуться с другим мыслительным процессом.
Подводя итог, можно сказать, что при структурированном подходе и ясности основ распределенных систем и достаточном количестве практики можно легко пройти собеседование по проектированию системы в любой технической компании.
