System Design: проектируем Dropbox, сервис для хранения и обмена файлами

[Dhwtj]

Без понимания экономики сервиса это всё пук в лужу.

Как увидел CDN и прочие потенциально дорогие решения сразу засомневался.

Также критично для экономики срок хранения файлов.

Не впадайте в архитектурный азарт, поставьте реальные цели и считайте каждую копейку

[pavsenin]

Здравствуйте, спасибо за комментарий!

Я не знаю, что вам ответить кроме цитаты из статьи относящейся к CDN:

Проблемы

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

[Dhwtj]

Вот, думаю, что для разработчика и для архитектора требования на собеседовании совсем разные.

Реактивный дизайн (решения всплывают по ходу, требования додумываются) на собеседовании большая ошибка, я считаю. Для разработчика ок, для архитектора нет.

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

А для архитектора не хватает

1. Оценки масштаба (количества пользователей всего и активных, размер хранилища, RPS, трафик) - без них решения берутся с потолка

2. Ранжирование сценариев по частоте - что оптимизируем в первую очередь

3. Ключевые архитектурные решения до коробочек: блочная модель/чанки, иммутабельность, разделение metadata/content, модель конфликтов

4. Экономика/себестоимость - дедуплиеация, tiering, лимиты как следствие экономики

Продвинутый дизайн системы: вы должны быть знакомы с современными принципами проектирования систем. Например, знать, как использовать объектное хранилище или как использовать CDN для более быстрой загрузки.

Нет, не должен))) 80% архитектурных ошибок отсеиваются на уровне здравого смысла (смотри выше), до технологий может и не дойти если задумка плохая

[pavsenin]

Вы правы, требования зависят от роли, на которую вы претендуете. В конце данной статьи подробно рассказываются примерные требования для Middle, Senior и Staff кандидатов (не буду цитировать, чтобы не перепечатывать в комментарии всю статью).

Конечно в разных компаниях (и даже у разных интервьюеров) они могут отличаться. Если у вас есть возможность узнать детали того как проходит System Design интервью именно в вашу целевую компанию - я всегда рекомендую кандидатам так делать. Это хорошо и для кандидата: он будет лучше готов, для него меньше неожиданностей. И для интервьюера: не нужно тратить время на объяснения, интервьюер за часовое интервью успевает собрать все сигналы по областям компетенций, которые необходимы для роли. Конечно в рамках того, что в принципе возможно собрать за час (но тут интервьюер находится в рамках процесса найма, установленных в компании).

Что касается функциональных, нефункциональных требований, структуры интервью, шаблонных и нешаблонных решений и их обоснований - это большая тема для обсуждения, ее невозможно рассказать в комментариях.

Хороший набор статей о том, как правильно готовиться и проходить интервью, как выбирать по-настоящему важные, интересные и нешаблонные темы для детальной проработки можно найти на платформе NowInterview.

[pavsenin]

А для архитектора не хватает

1. Оценки масштаба (количества пользователей всего и активных, размер хранилища, RPS, трафик) - без них решения берутся с потолка

Здесь я с вами соглашусь лишь частично. Умение все это считать - требование для Middle кандидата. Неопытные кандидаты очень часто тратят на оценки слишком много времени, игнорируя большую часть результатов этих оценок. Staff+ кандидаты не тратят время на оценки, если они не имеют прямого непосредственного влияния на конкретную часть дизайна, которая сейчас рассматривается. Если прямо сейчас кандидат обсуждает нужно ли шардировать базу - самое время сделать оценки масштаба для принятия этого решения, это разумно. Но если кандидат просто посмотрел 10+ шаблонных видео на ютуб, в которых все так делают в начале интервью и поэтому он сделает так же - чтобы выглядеть "как архитектур" - это бесполезно, опытный интервьюер легко это считает.