Подготовка к интервью по системному дизайну (System Design Interview)

Часть 3.

Предыдущие статьи : Часть 1, Часть 2. Прежде чем читать эту статью, рекомендую прочитать предыдущую, что бы было понятно о чем идет речь.

Шаг 5. Высокоуровневый дизайн.

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

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

Шаг 6. Детальный дизайн.

Копаем глубже в 2–3 компонента. Обратная связь от интервьюера должна всегда вести вас к тому, какие части системы он хочет что бы вы объяснили дальше. Вы должны быть способны обеспечить различные подходы, их плюсы и минусы, и почему вы хотите выбрать один из них.

Помните тут нет одного ответа, есть только 1 важная вещь — это рассмотреть компромиссы между различными вариантами, учитывая системные ограничения.

— Так как мы будем хранить огромное количество данных, как мы должны разделить данные для распределения/хранения их в нескольких базах данных. Должны ли мы хранить всю информацию о пользователе в одной базе? Какие проблемы это может вызвать?

— Как мы будем отслеживать “горячих” пользователей, которые много “твитят” или подписаны на множество людей?

— Так как лента новостей будет содержать недавние и наиболее релевантные (актуальные) твиты, должны ли мы попробовать разместить наши данные таким образом, чтобы оптимизировать сканирование (поиск) последних твитов?

— Сколько и на каком уровне мы должны ввести кэш для ускорения процесса?

— Какие компоненты требуют лучшей балансировки нагрузки?

Шаг 7. Определение и устранение узких мест (resolving bottlenecks).

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

— Есть ли единственная точка отказа в нашей системе? Что сделать что бы смягчить ее?

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

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

— Как мы мониторим производительность наших сервисов? Нужны ли нам оповещения если критичный компонент вышел из строя или его производительность снизилась?

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

Дальше мы попробуем спроектировать сервис на подобии TinyURL.