How to Design a Music Streaming Service Like Spotify
Learn how to design a Spotify-like service: CDN chunked delivery, adaptive bitrate streaming, and offline recommendation pipelines.
Expected Interview Answer
A Spotify-like music streaming service stores audio tracks as pre-transcoded chunked files in object storage served through a CDN, uses adaptive bitrate streaming for smooth playback, and separates the catalog/metadata service, the streaming/delivery path, and the recommendation pipeline into independently scalable subsystems.
Tracks are uploaded once, transcoded server-side into several bitrates and chunked into small segments (similar to HLS/DASH), then pushed to object storage and fronted by a CDN so playback requests are served from an edge location close to the listener rather than a central data center. A metadata service holds track, album, artist and playlist data in a relational or document store, separate entirely from the audio bytes, and playback clients request a short-lived signed URL for each chunk after checking entitlement (subscription/DRM) with an auth service. Adaptive bitrate logic on the client monitors network conditions and switches between pre-transcoded quality levels chunk-by-chunk to avoid buffering. A separate, asynchronously updated recommendation pipeline consumes play-event streams (via Kafka) to build collaborative-filtering and content-based models offline, serving personalized playlists like Discover Weekly from a precomputed cache rather than computing recommendations live on every request.
- CDN-fronted chunked delivery keeps playback low-latency and resilient to regional load
- Adaptive bitrate streaming avoids buffering across varying network conditions
- Separating metadata, streaming, and recommendations lets each scale and evolve independently
- Offline-computed recommendations keep personalized playlist requests fast and cheap to serve
AI Mentor Explanation
Designing a music-streaming service is like broadcasting a match to millions of homes: the raw camera feed is transcoded into multiple quality streams in advance and distributed to regional relay towers instead of every viewer pulling from one central studio. A viewer’s set-top box picks the best quality stream for its current signal strength and switches smoothly if reception dips, exactly like adaptive bitrate streaming. Meanwhile, a completely separate team analyzes viewing patterns overnight to recommend which upcoming matches a fan might enjoy, without slowing down the live broadcast pipeline. That split between low-latency delivery infrastructure and offline personalization mirrors exactly how a service like Spotify is architected.
Step-by-Step Explanation
Step 1
Transcode and chunk audio on upload
Tracks are pre-processed into multiple bitrates and small chunks, then pushed to object storage.
Step 2
Serve playback through a CDN
Clients request signed, short-lived chunk URLs from CDN edge nodes close to the listener, after an entitlement check.
Step 3
Adapt bitrate on the client
The player monitors buffering/network conditions and switches between pre-transcoded quality levels per chunk.
Step 4
Build recommendations offline
A separate pipeline ingests play events via a stream and precomputes personalized playlists asynchronously, served from cache.
What Interviewer Expects
- Separates catalog/metadata, audio delivery, and recommendation systems as independently scalable pieces
- Explains pre-transcoding and CDN-based chunked delivery rather than live transcoding per request
- Describes adaptive bitrate streaming and why it matters for playback quality
- Recognizes that recommendations are computed asynchronously/offline, not on the hot playback path
Common Mistakes
- Proposing to transcode audio live on every playback request instead of pre-processing once
- Serving all audio from a single origin server instead of a CDN
- Coupling recommendation computation into the synchronous playback request path
- Forgetting entitlement/DRM checks before issuing chunk URLs
Best Answer (HR Friendly)
“To design something like Spotify, I would pre-process every track into multiple quality levels once, store it in a CDN so it plays fast anywhere in the world, and have the app automatically adjust quality based on the listener’s connection so it never stutters. I would keep the recommendation engine completely separate, building personalized playlists in the background from listening history instead of computing anything live when someone just wants to hit play.”
Code Example
ingestion:
onUpload:
- transcode:
bitrates: [96kbps, 160kbps, 320kbps]
- chunk:
segmentSeconds: 6
- pushTo: objectStorage
- registerIn: metadataService
playback:
entitlementCheck: authService
chunkUrl:
source: cdn
signedUrlTtlSeconds: 60
clientAdaptiveBitrate:
strategy: bufferHealthAndBandwidth
recommendations:
eventStream: kafka.play-events
pipeline:
- collaborativeFiltering
- contentBasedModel
refreshSchedule: nightly
servedFrom: precomputedCacheFollow-up Questions
- How would you implement adaptive bitrate switching without introducing audible glitches?
- How would you design Discover Weekly so it feels personalized without computing it live?
- How would you handle offline downloads and DRM for a mobile client?
- How would you scale the metadata/catalog service separately from audio delivery?
MCQ Practice
1. Why pre-transcode tracks into multiple bitrates ahead of time rather than transcoding live on each request?
Transcoding once and caching the outputs is far cheaper than re-encoding on every play, and lets a CDN serve the same cached chunks to many listeners.
2. What is the primary purpose of adaptive bitrate streaming?
Adaptive bitrate streaming continuously matches playback quality to available bandwidth, minimizing stalls while maximizing quality.
3. Why compute recommendations like Discover Weekly asynchronously/offline instead of live on request?
Precomputing recommendations offline from batched play-event data keeps the hot request path fast and avoids expensive model computation per request.
Flash Cards
Why pre-transcode and chunk audio? — So playback can be served as cached, CDN-delivered chunks instead of expensive live transcoding per request.
What is adaptive bitrate streaming? — Client-side logic that switches between pre-encoded quality levels chunk-by-chunk based on network conditions.
Why separate the recommendation pipeline? — So expensive offline model computation from play-event streams never blocks or slows the live playback path.
What checks happen before a chunk URL is issued? — Entitlement/subscription and DRM checks via an auth service before a signed, short-lived URL is returned.