Spotify Music Streaming – System Design Interview Preparation

Practice designing a music streaming service like Spotify. Cover audio streaming, playlists, recommendations, and offline mode.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Spotify design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Spotify is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Low time-to-first-audio with gapless playback, and a recommendation system whose output is precomputed rather than queried live.

Scale to establish before drawing anything

100M tracks, each a few MB per quality tier - large but finite, and heavily skewed in popularity.
Playback start must feel instant, which means the first seconds are prefetched before the user presses play.
Listening events are the dominant write volume and feed everything downstream.

Core components

Audio storage and CDN – Tracks in several bitrates, served from the edge.
Streaming service – Issues signed, expiring URLs and enforces licensing by region.
Client prefetch – Downloads the next track's opening while the current one plays. This is what makes it feel gapless.
Playlist service – User and editorial playlists, read-heavy, cached.
Recommendation pipeline – Collaborative filtering computed offline, served as a precomputed row set per user.
Event pipeline – Play, skip and complete events feeding both recommendations and royalty accounting.

Trade-offs to defend

Prefetch aggressiveness – Prefetching the next three tracks guarantees smoothness and wastes bandwidth on skips. Skip rate is the number that settles it.
Offline downloads – Encrypted local caching with licence expiry is a separate subsystem, not a bigger cache.
Recommendations offline versus real time – Offline is cheap and stale. A small real-time signal layered on an offline base is the usual compromise.

Follow-up questions to expect

A playlist is shuffled. Which track do you prefetch?
A new album drops and 10M users play it at once. Which part of your design is already prepared?
Licensing removes a track in one country only. Where is that enforced?