System Design: Spotify

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

В этой статье автор показывает, как бы он спроектировал Spotify на собеседовании. Решение получилось очень любопытным и при этом достаточно простым. Правда, я споткнулся на терминологии leader-follower (не сразу понял, что теперь master-slave так называется).

Тем, кому предстоит проходить подобное собеседование, рекомендую также обратить внимание на последовательность шагов, которые предпринимает автор. Сначала он выяснил требования и посчитал циферки, а только потом начал рисовать. Не наоборот.

В примере, конечно, не хватает ряда цифр (например, расчёта RPS) и адекватного проектирования бэкенда (web servers — это сильно). Но сама идея как минимум достойна изучения. У меня в закладках есть более интересные примеры проектирования таких систем, так что ждите новых постов.

⭐️ Интересные идеи

➡️ Основная проблема — для песен нужно много места (90 ТБ). Для их хранения автор выбрал обычное файловое хранилище (типа S3). Метаданные хранятся в обычной реляционной базе — их совсем немного.

➡️ Боттлнеком в такой системе становится нагрузка на сеть. Если постоянно читать все песни и гонять трафик, то в какой-то момент пропускной способности просто перестанет хватать. Решение простое — внедрить региональные CDN, которые будут кэшировать и раздавать песни по своей области покрытия.

➡️ На самом деле под капотом Spotify работает по запатентованному P2P-протоколу синхронизации, поэтому у них в системе нет централизованного хранилища. Эта информация есть в первом комментарии к статье — там же содержится ссылка на сам документ с описанием протокола.

Приятного чтения!

#systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи