Spotify

Music Streaming

Design a music streaming service at the system level: a catalog of 100 million tracks, playback that starts in a fraction of a second on any network, playlists, offline listening, play counting for royalties, and recommendations.

Overview

A music streaming service lets people play any track in a very large catalog, instantly, on phones, desktops, browsers, cars and speakers. Behind the play button there are three different systems: a delivery system that gets audio bytes to the device fast, a catalog and library system for tracks, albums, artists and playlists, and a data system that turns every play into royalty payments and recommendations.

Audio is easier than video in one way: a track is a few megabytes, not gigabytes. It is harder in another: people skip constantly, so the service must start a new track many times an hour, and a gap or a stall is noticed at once. Popularity is also very uneven, which is what makes caching work.

This is the system design version. For classes and objects (Track, Playlist, Player), see the Spotify topic in Low Level Design. The general patterns reused here are covered in the Handling Large Blobs and CDN vs Direct Serving topics.

Questions to ask first

Catalog size? — About 100 million tracks, growing every day
Listeners? — 300 million a day, 90 minutes each on average
Quality levels? — Several bitrates up to 320 kbps, plus lossless for paid users
Offline? — Yes, for paid users, with limits
Recommendations in scope? — At a high level: where they come from and how they are served
Royalties? — Every counted play must be attributed and auditable

What you will be able to do

Walk through what happens between pressing play and hearing sound, and why it can take well under a second.
Size audio storage and bandwidth, and explain why a CDN with a small hot set works.
Design playlists that several people can edit safely.
Build the play event pipeline that counts streams for royalties.
Describe recommendations as candidate generation plus ranking, served in batch and in real time.

Key concepts

Catalog and metadata
Encodings and bitrates
CDN and popularity skew
Prefetch for gapless play
Content keys and offline licenses
Playlist snapshots
Play event pipeline
30-second stream rule
Embeddings and nearest neighbors
Connect: control vs playback device

Functional requirements

Search the catalog and play any track, with seeking
Choose audio quality, or let the app adapt to the network
Create, edit, share and follow playlists; collaborative playlists
Download music for offline listening on paid plans
Control playback on another device (a speaker, a computer) from the phone
Personalized playlists and recommendations
Count plays for royalties and artist statistics

Non-functional requirements

Playback starts within 500 ms at p90 on a good connection (a target we chose)
No gap between tracks that should play continuously
Playback keeps going through short network drops
Every counted play is recorded exactly once for royalties, even if it arrives late (offline)
The catalog stays playable during a region outage

Interview questions

What happens between pressing play and hearing sound?
How much storage and bandwidth does the catalog need?
Why does a CDN work so well for music?
How do you count streams for royalties correctly?
How would you design collaborative playlists?
How do recommendations work, at a system level?
How does offline playback stay secure?
How would you move playback from a phone to a speaker?