Что происходит после нажатия Play. Разбираем архитектуру Spotify
Всем привет. На днях попалась информация интересная и захотелось разобраться в сервисе, которым пользуются миллионы людей – это Spotify.
На первый взгляд всё очень просто, нашли песню, нажали Play, музыка заиграла, но, если вспомнить, что за этим приложением стоят миллионы пользователей и миллионы треков, всё становится гораздо сложнее и интереснее.
Где физически лежит музыка? Почему один и тот же трек существует в нескольких версиях? Кто отправляет аудио пользователю? Почему Spotify не отдаёт весь файл через свой backend? Как музыка успевает загрузиться раньше, чем мы до неё дослушали? И откуда приложение знает, где мы остановились на другом устройстве?
Давайте разберёмся.
Хранение музыки
В Spotify миллионы треков, и аудио должно подходить разным устройствам, настройкам качества и условиям соединения. Поэтому при подготовке музыки Spotify работает не с одним универсальным представлением аудио. Аудио проходит внутреннюю обработку и оптимизацию форматов для последующего воспроизведения. В зависимости от устройства, подписки и настроек пользователя сервис может использовать подходящее представление аудио.
Пользователю при этом не нужно отдельно получать все возможные варианты файла, Spotify автоматически выбирает подходящий формат и качество в зависимости от его устройства, интернета, настроек и других условий.
Например, может понадобиться версия с низким битрейтом для медленного мобильного интернета, версия с более высоким качеством для пользователей Premium, а также разные кодеки для разных устройств.
После обработки аудиофайлы должны быть доступны инфраструктуре хранения и доставки по всему миру. И возникает вопрос, а что происходит, когда пользователь нажимает Play?
https://support.spotify.com/nl/article/audio-quality/
https://support.spotify.com/cg-en/artists/article/audio-file-formats/
Воспроизведение музыки
Когда пользователь нажимает Play, Spotify должен определить, кто пользователь, какой трек он запросил, доступен ли этот трек в его регионе и какое состояние воспроизведения сейчас актуально. Но backend не должен сам отдавать каждый байт звука. Это быстро стало бы огромным узким местом.
Вместо этого, когда Spotify понимает, что тебе можно слушать этот трек, его начинают отдавать серверы, которые находятся гораздо ближе к пользователю – CDN сервера.
Получается разделение двух задач, где backend просто управляет воспроизведением, а CDN занимается доставкой самого аудио.
Backend решает, что должно произойти, а CDN везёт тяжёлый аудиотрафик.
Буферизация и качество воспроизведения
Важная задача - обеспечить, чтобы музыка начинала играть почти сразу и не прерывалась при каждом небольшом ухудшении соединения.
Никто не хочет нажать Play и несколько секунд ждать загрузки песни. Поэтому приложение не скачивает весь трек целиком перед началом воспроизведения. Spotify получает аудио постепенно, частями, используя HTTP Range Requests. В опубликованном инженерном материале компании упоминаются аудиочанки размером около 512 КБ.
Это позволяет начать воспроизведение сразу после получения первых данных, а остальные части загружать параллельно с прослушиванием. Пока пользователь слушает начало трека, следующие фрагменты уже могут находиться на устройстве и ждать своей очереди.
Это буфер. Он служит небольшим запасом данных между сетью и плеером. Если соединение на несколько секунд станет медленнее, плеер продолжит брать данные из уже загруженного запаса. Проблемы начинаются тогда, когда новые данные поступают медленнее, чем плеер их воспроизводит. Буфер постепенно уменьшается и в какой-то момент может закончиться. Такое состояние называется buffer underrun и именно оно приводит к паузам и прерываниям воспроизведения. Spotify отдельно отслеживает такие ситуации как один из показателей качества стриминга.
При этом нужно найти баланс. Если начать воспроизведение сразу, ещё до того, как накопился большой запас данных, пользователь меньше ждёт, но вероятность прерывания при нестабильной сети становится выше. Если же сначала долго заполнять буфер, воспроизведение будет устойчивее, но возрастёт задержка перед первым звуком.
Spotify поэтому смотрит не только на сам факт начала воспроизведения, но и на то, насколько стабильно оно продолжается. В материале компании отдельно рассматриваются playback latency — время до начала воспроизведения — и stutter, то есть прерывания во время прослушивания.
Когда сеть работает нестабильно, пользователю не обязательно всегда передавать аудио в максимальном качестве. Spotify поддерживает автоматический выбор качества и в определённых случаях может снизить его, чтобы уменьшить вероятность проблем с буферизацией.
Spotify экспериментировал даже с более низким уровнем этой системы - сетевым транспортом. Например, в 2018 году компания сравнивала обычный TCP congestion control с BBR и сообщала о снижении stutter на 6–10% и росте пропускной способности на 10–15% для пользователей с более медленным соединением. При этом заметной разницы в playback latency обнаружено не было.
https://engineering.atspotify.com/2018/08/smoother-streaming-with-bbr
https://support.spotify.com/nl/article/audio-quality/
Spotify и P2P
Кстати, до 2014 года Spotify раздавал музыку ещё и через P2P, прямо с компьютеров других слушателей.
Более того, клиент мог одновременно использовать несколько источников. Например, при запросе нового трека он мог обратиться к серверу Spotify и параллельно искать подходящих peers. А если соединение с одним из них было слишком медленным, данные можно было запросить у другого пира или у сервера.
В 2014 году Spotify начал постепенно отказываться от P2P. Компания объясняла это тем, что инфраструктура серверов уже достаточно выросла и теперь могла обеспечивать доставку музыки без необходимости использовать desktop P2P.
Но цифры 8,8%, 35,8%, 55,4% и 265 мс – это уже история старого Spotify, а не показатели современной системы.
Сегодня P2P уже не является частью архитектуры доставки музыки Spotify. Компания перешла к серверной инфраструктуре и использованию CDN. В своих инженерных материалах Spotify описывает доставку.
https://engineering.atspotify.com/2021/08/four-lessons-we-learned-from-creating-spotifys-desktop-app
https://kreitz.se/spotify-p2p10/spotify-p2p10.pdf
Поиск
Представим, что ты открываешь Spotify и вводишь название песни, например Blanding Lights.
На первый взгляд кажется, что дальше нужно просто найти совпадение в базе. Но у Spotify миллионы объектов, а поиск должен работать не только по названиям треков. Пользователь может искать исполнителя, альбом, подкаст, а иногда вообще формулировать запрос не теми словами, которые встречаются в названии результата.
Поэтому поиск — это отдельная большая подсистема.
Spotify давно развивает собственную поисковую инфраструктуру. В компании отдельно работают над тем, как получать данные для поиска, как обрабатывать поисковые запросы, как формировать персонализированные результаты и как оценивать их качество. Сам Spotify описывает такие этапы, как понимание намерения пользователя, retrieval - получение подходящих кандидатов и ранкинг, то есть их последующая сортировка.
Текстовый поиск
Один из самых очевидных способов, это искать совпадения в индексированных данных, таких как названии трека, имени исполнителя, названии альбома и других метаданных.
Но точного совпадения бывает недостаточно. Пользователь может допустить опечатку, использовать другую форму слова или просто сформулировать запрос иначе.
Spotify сам пишет, что раньше их поиск в основном опирался на term matching - совпадение слов запроса с индексированными метаданными. Для улучшения результатов использовались fuzzy matching, нормализация и алиасы.
Например, если пользователь ищет:
electric cars climate impactобычный текстовый поиск пытается найти материалы, содержащие соответствующие слова. Но что делать, если подходящий результат существует, а в его названии этих слов вообще нет? Здесь уже требуется семантический поиск.
Семантический поиск
Вместо простого сравнения строк можно превратить запрос и объект поиска в числовые векторы - embeddings.
Тогда, вместо того что бы искать слова внавзнании, система пытается понять, насколько смысл запроса похож на смысл этого материала?»
Spotify применял такой подход, например, для поиска эпизодов подкастов. Запрос и описание эпизода преобразуются в векторы, после чего система быстро ищет близкие векторы с помощью Approximate Nearest Neighbor (ANN).
Условно:
"electric cars climate impact" -> Embedding -> [0.12, -0.31, ...] -> Vector search -> Episode A Episode B Episode CПричём это не обязательно означает, что обычный текстовый поиск заменяется векторным.
В описанной Spotify архитектуре семантический поиск стал дополнительным источником кандидатов наряду с существующими механизмами, включая Elasticsearch. После этого кандидаты объединяются и проходят финальное ранжирование.
В итоге, поиск поиск это не просто запрос к базе данных.
Сначала нужно найти достаточно большой набор потенциально подходящих результатов, а затем определить, какие из них показать пользователю в первую очередь. На ранжирование могут влиять разные признаки, а сам Spotify отдельно работает над качеством персонализированного поиска.
При этом часть поиска можно выполнять очень быстро благодаря заранее построенным индексам. Например, Spotify использует approximate nearest-neighbor технологии уже много лет и применяет их не только в рекомендациях, но и в поисковой инфраструктуре. В 2023 году компания представила Voyager - библиотеку поиска ближайших соседей, которая должна была заменить Annoy в production-системах Spotify.
Поэтому поиск в Spotify это уже не один индекс, а целая цепочка:
Запрос - Понимание запроса - Получение кандидатов - Текстовый / семантический поиск - Объединение результатов - Ranking - Результаты пользователю
И это отдельная большая система, которая работает рядом с основной инфраструктурой Spotify, а не заставляет основную базу каждый раз перебирать миллионы записей.
https://engineering.atspotify.com/2021/04/rethinking-spotify-search
Рекомендации
Что этот пользователь послушает дальше? Что попадёт в Discover Weekly? Какая песня включится после этой?
Здесь недостаточно просто посмотреть на популярные треки. Одному пользователю может нравиться рок, другому электронная музыка, а третий сегодня слушает джаз, хотя обычно предпочитает хип-хоп.
Поэтому рекомендации строятся с учётом поведения конкретного пользователя. Spotify может использовать историю прослушиваний, пропуски, сохранённые треки, плейлисты, артистов и связи между самими песнями. Компания описывала Discover Weekly как персональный плейлист, который учитывает не только собственное прослушивание пользователя, но и то, что слушают и добавляют в плейлисты другие люди.
Кроме истории пользователя, можно анализировать и сами треки. Spotify пишет, что его алгоритмы могут находить сходства между песнями и определять, какие композиции часто слушают вместе. Затем история конкретного пользователя объединяется с этими связями, чтобы получить персональный набор треков.
Получается примерно такая логика: пользователь что-то слушает, пропускает одни песни, сохраняет другие, добавляет композиции в плейлисты и все эти действия становятся сигналами для системы рекомендаций.
Причём система не просто один раз строит профиль пользователя и забывает о нём. Его предпочтения постоянно меняются. Если последние несколько дней человек слушает совсем другую музыку, рекомендации тоже должны постепенно измениться.
Spotify пишет, что действия пользователя прослушивания, пропуски и сохранения треков - используются для обучения recommendation engine и обновления представления о вкусах слушателя.
Но когда именно всё это вычислять?
Представим, что пользователь открывает приложение. Было бы не очень разумно в этот момент начинать с нуля анализировать всю его историю прослушиваний, искать похожие треки, строить кандидатов и только потом формировать рекомендации.
Часть работы можно выполнять заранее. Например, периодически обрабатывать накопившуюся историю и готовить данные, которые потом будут использоваться при формировании рекомендаций.
Но на этом всё не заканчивается. Система Spotify также умеет работать с данными почти в реальном времени. В опубликованном в январе 2026 года материале Spotify пишет, что инфраструктура персонализации использует real-time data collection, low-latency access к признакам пользователя и быстрый расчёт рекомендаций непосредственно во время запроса.
Поэтому современную систему рекомендаций лучше представить не как один заранее рассчитанный плейлист, а как комбинацию нескольких этапов, где часть данных и моделей подготавливается заранее, а часть решения принимается уже в момент запроса с учётом актуального контекста пользователя.
Кроме того, рекомендации нужно не только построить, но и постоянно улучшать. Spotify отдельно разделяет инфраструктуру персонализации и инфраструктуру экспериментов: ML-система отвечает за построение и выдачу рекомендаций, а экспериментальная платформа позволяет сравнивать разные версии этих систем и проверять, какие из них действительно работают лучше.
Это тоже важная часть архитектуры. Даже очень хорошая модель не означает, что она всегда будет показывать лучший результат. Поэтому Spotify может запускать эксперименты, сравнивать варианты рекомендаций и смотреть, как пользователи на них реагируют.
Что происходит, когда выходит новый альбом
Теперь представим другую ситуацию. В полночь выходит новый альбом огромной звезды. Миллионы людей одновременно начинают запрашивать одни и те же песни.
Это отличный случай для кеширования в CDN. Первый запрос к конкретному треку может прийти на edge-сервер, где этого аудио ещё нет. Тогда CDN получает нужные данные из исходного хранилища, сохраняет их в своём кеше и отдаёт пользователю.
Следующие запросы к этому же треку уже могут обслуживаться непосредственно из кеша. Пользователю не приходится каждый раз ждать, пока данные придут из центрального хранилища.
Получается примерно такая цепочка:
Первый запрос Пользователь - CDN - Исходное хранилище - cache
Следующие запросы - Пользователь - CDN - cache
И чем популярнее трек, тем больше запросов можно обслужить на edge-серверах, не создавая дополнительную нагрузку на центральное хранилище.
Особенно это полезно в моменты резкого роста нагрузки, например сразу после выхода нового альбома.
Синхронизация между устройствами
И наконец, Spotify должен синхронизировать состояние воспроизведения между устройствами.
Сценарий: ты слушаешь песню на ноутбуке, ставишь её на паузу, а потом открываешь Spotify на телефоне. Телефон должен понимать, какой трек сейчас воспроизводился, на каком месте остановилось воспроизведение и какое устройство было активным.
Для этого Spotify использует Spotify Connect. Компания предоставляет отдельный Player API, через который можно получать информацию о доступных устройствах и текущем состоянии плеера, а также управлять воспроизведением на выбранном устройстве.
Например, запрос текущего состояния воспроизведения позволяет получить активное устройство, текущий трек, текущую позицию в миллисекундах, время последнего изменения состояния и признак того, играет ли сейчас музыка.
При этом Spotify умеет работать сразу с несколькими устройствами пользователя. Через отдельный API можно получить список доступных устройств, компьютер, смартфон, Web Player или колонку и выбрать нужное устройство для воспроизведения.
Получается, что Spotify хранит не просто факт, что пользователь слушает песню, а более полное состояние плеера, которое позволяет управлять воспроизведением и понимать, что сейчас происходит на устройствах пользователя.
И это уже отдельная задача от самой доставки аудио. Одни системы отвечают за передачу музыкальных данных, а другая часть инфраструктуры должна быстро предоставить актуальное состояние плеера и устройств.
https://engineering.atspotify.com/2022/04/spotifys-player-api
Заключение
За обычным нажатием Play скрывается гораздо больше, чем кажется и выходит, что сложность Spotify не в том, чтобы просто проиграть аудиофайл. Сложность в том, чтобы для миллионов пользователей по всему миру песня начинали играть мгновенно в лучшем формате и с того же места. А мы видим просто кнопку «Play».
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.