Конспект книги Alex Xu "System Design"

Книга рассказывает о правилах и лайфхаках прохождения system-design интервью. В начале рассказываются базовые определения system-design, объясняются термины, которые в дальнейшем будут использоваться. Также дополнительно объясняется механизм приблизительных оценок.

Далее каждая глава представляет собой конкретный кейс по проектированию системы определённого типа.

В ходе главы разбирается флоу стандартного system-design собеседования:

1. Понять задачу и определить масштаб решения
• выясните тип приложения: мобильное, веб-приложение, десктопное, одновременно несколько типов;
• основные функциональные требования приложения - какие основные фичи, что наиболее приоритетно;
• основные нефункциональные требования - количество пользователей, количество действий пользователя в системе, максимальные размеры медиафайлов (если они присутствуют).
2. Предложить общее решение и получить согласие На начальном этапе достаточно обозначить архитектуру решения крупными мазками. Степень абстракции зависит от задачи. Если вы проектируете youtube - можно ограничиться основными элементами решения - backend-сервисами, хранилищами данных, очередями. Если же проектируете только backend-часть какой-то системы учёта - возможно потребуется спуститься до общего описания API-методов и более подробного рассказа об используемых хранилищах данных. Кроме того разделите общие функциональности системы - предусмотрите, что основные функциональные требования выполнимы по вашему общему решения. Например, если проектируете новостную ленту - это может быть чтение постов из ленты и публикация постов в ленту. В любом случае, уточняйте степень погружения у интервьюера.
• предложите начальный план архитектуры - постоянно обсуждайте его с интервьюером, подсвечивайте ваши опасения и трейдоффы, которые вы соблюдаете;
• выполните предварительные расчёты чтобы обосновать, что ваше предварительное решение соответствует масштабу нагрузки.
3. Погружение в детали Исходя из приоритетов функциональных требований - спуститесь на уровень ниже и подробно расскажите о реализации конкретной функциональности. Степень погружения уточняйте у интервьюера. На этом этапе, возможно, потребуется спроектировать API и общие схемы используемых хранилищ данных - например, таблицы, если используются реляционные БД.
4. Подведение итогов
• обозначьте узкие места системы, сделайте акцент на трейдоффах, на которые вам пришлось пойти;
• расскажите потенциальные улучшения вашей архитектуры и объясните причины, почему их нельзя было применить прямо сейчас, а можно только через какое-то время;
• обсудите как ваша архитектура поведёт себя во внештатных ситуациях - поломка серверов, разрыв сети;
• обсудите вопросы эксплуатации - метрики, отслеживание ошибок, логи;
• обсудите масштабирование - рассмотрите вопрос внепланового масштабирования - например, на фоне мощного роста популярности вашей системы.

Основные лайфхаки по прохождению таких интервью:

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

Далее прикладываю mind-map со списком вещей, которым необходимо уделить внимание при проектировании каждой системы: