Design a music streaming and recommendation service like Spotify.

Question

Anonymous · Accepted Answer

1. START BY CLARIFYING REQUIREMENTS

Say something like:

> “I’ll design a Spotify-like service focused on music discovery and playback.
> I’ll first clarify functional and non-functional requirements, estimate scale,
> then design the high-level architecture. After that, I’ll deep dive into
> streaming and recommendations.”

FUNCTIONAL REQUIREMENTS

I would prioritize:

1. Search songs, artists, albums and playlists.

2. Play/pause/seek/skip music.

3. Create and manage playlists.

4. Like/save songs.

5. Track listening history.

6. Recommend songs and playlists.

7. Personalized home feed.

8. Continue playback across devices.

Then explicitly say:

> “I’ll leave podcasts, payments, social features, artist uploads and ads
> outside the initial scope.”

That shows good scoping.

--------------------------------------------------------------------------------

2. NON-FUNCTIONAL REQUIREMENTS

Mention:

* High availability — playback should almost always work.

* Low playback-start latency — ideally a few hundred milliseconds after enough
   audio is buffered.

* Global scalability.

* High durability for music files and metadata.

* Eventual consistency is acceptable for likes, history and recommendations.

* Stronger consistency is useful for account/security operations.

* Recommendations should update as user behavior changes.

* System should tolerate regional/server failures.

One important observation:

> “Streaming audio is read-heavy, so I want to avoid sending audio through
> application servers. Audio should be served primarily from object storage
> through a CDN.”

That is one of the key design decisions.

--------------------------------------------------------------------------------

3. BACK-OF-THE-ENVELOPE ESTIMATION

You don't need perfect numbers.

Assume:

500M users

200M DAU

If each active user streams approximately 2 hours/day:

200M × 2 hours = 400M streaming hours/day

If average encoded bitrate is around 160 kbps:

160 kbps ≈ 20 KB/sec.

One hour:

20 KB × 3600 ≈ 72 MB

Therefore:

400M × 72 MB ≈ 28.8 PB/day of audio delivered

Then say:

> “This immediately tells us that CDN architecture is critical. Our backend
> should not serve tens of petabytes of audio directly.”

That's more valuable than calculating an exact number.

--------------------------------------------------------------------------------

4. DRAW THE HIGH-LEVEL ARCHITECTURE

In an interview, draw something approximately like this:

┌─────────────────┐
                         │ Mobile / Web App│
                         └────────┬────────┘
                                  │
                                  ▼
                         ┌─────────────────┐
                         │ API Gateway / LB│
                         └────────┬────────┘
                                  │
          ┌───────────────────────┼────────────────────────┐
          │                       │                        │
          ▼                       ▼                        ▼
   ┌─────────────┐        ┌──────────────┐        ┌──────────────┐
   │ User Service│        │Search Service│        │Playlist Svc  │
   └──────┬──────┘        └───────┬──────┘        └──────┬───────┘
          │                       │                        │
          ▼                       ▼                        ▼
      User DB               Search Index              Playlist DB

PLAYBACK PATH

Client
  │
  │ GET /tracks/{id}/playback
  ▼
Playback Service
  │
  │ authorization / entitlement
  ▼
Returns signed CDN URL
  │
  ▼
Client ───────────────► CDN ─────────────► Object Storage
                        │
                        └── cached audio chunks

USER EVENT PIPELINE

Client
   │
   │ play / skip / like / search
   ▼
Event Collector
   │
   ▼
Kafka / Event Bus
   │
   ├────────► Listening History
   │
   ├────────► Analytics
   │
   └────────► Recommendation Pipeline
                       │
                       ▼
               Feature / Embedding Store
                       │
                       ▼
               Recommendation Service
                       │
                       ▼
                  Home Feed

Now walk through each component.

--------------------------------------------------------------------------------

5. API DESIGN

Show a few important APIs rather than dozens.

SEARCH

GET /v1/search?q=weeknd&type=track,artist

Response:

{
  "tracks": [
    {
      "track_id": "123",
      "title": "Blinding Lights",
      "artist": "The Weeknd"
    }
  ]
}

GET TRACK METADATA

GET /v1/tracks/{track_id}

PLAYBACK

GET /v1/tracks/{track_id}/playback

Response:

{
  "manifest_url": "https://cdn.example.com/...",
  "expires_at": "..."
}

Important:

Don't return the actual audio through this API.

The API authenticates the user and returns a temporary/signed URL or streaming
manifest.

PLAYLIST

POST /v1/playlists

POST /v1/playlists/{playlist_id}/tracks

DELETE /v1/playlists/{playlist_id}/tracks/{track_id}

USER EVENT

POST /v1/events

{
  "user_id": "U123",
  "track_id": "T456",
  "event": "skip",
  "timestamp": "..."
}

--------------------------------------------------------------------------------

6. DATA MODEL

Explain that different workloads need different databases.

USER

User
----
user_id
name
country
subscription_type
created_at

TRACK

Track
-----
track_id
title
artist_id
album_id
duration
genre
release_date
audio_object_key

PLAYLIST

Playlist
--------
playlist_id
user_id
name
created_at

PLAYLISTTRACK

playlist_id
track_id
position
added_at

LISTENING EVENT

ListeningEvent
--------------
user_id
track_id
event_type
timestamp
device
session_id

Then make the important system-design point:

> “I wouldn't necessarily put all of these into the same relational database.”

For example:

DataTechnologyUser/accountSQLTrack metadataSQL / distributed DBAudio filesObject
storageSearchElasticsearch/OpenSearch-style indexPlaylist dataDistributed DB /
SQL depending scaleSessions/cacheRedisEventsKafkaListening
historyCassandra/DynamoDB-style storeML featuresFeature/embedding store

You don't need to defend specific vendors unless asked. Defend the properties
you need.

--------------------------------------------------------------------------------

7. DEEP DIVE #1: MUSIC STREAMING

This is probably the most important part.

Suppose the user presses Play.

STEP 1 — CLIENT REQUESTS PLAYBACK

Client
   ↓
GET /tracks/123/playback

Playback service checks:

* Is user authenticated?

* Is track available in user's country?

* Does subscription allow playback?

* Is content restricted?

* Which audio quality should be used?

--------------------------------------------------------------------------------

STEP 2 — RETURN MANIFEST/CDN LOCATION

Instead of downloading:

song.mp3

as one huge file, store multiple encoded versions:

track123/
   64kbps/
   128kbps/
   256kbps/
   320kbps/

And break audio into chunks.

For example:

track123/

128kbps/
   chunk001
   chunk002
   chunk003
   ...

320kbps/
   chunk001
   chunk002
   chunk003

Why?

Because this allows:

* seeking

* buffering

* adaptive quality

* quick startup

* efficient CDN caching

--------------------------------------------------------------------------------

8. ADAPTIVE BITRATE STREAMING

Explain:

> “The client monitors bandwidth and buffer health and can choose an appropriate
> bitrate.”

For example:

Fast Wi-Fi
      ↓
320 kbps

Bandwidth drops
      ↓
128 kbps

Bandwidth improves
      ↓
256/320 kbps

This reduces buffering.

You can mention technologies such as HLS/DASH conceptually, although the exact
production implementation doesn't matter.

--------------------------------------------------------------------------------

9. WHY CDN?

Without CDN:

Atlanta User
      ↓
Origin server

Every request travels to your origin.

With CDN:

Object Storage
                       │
                       ▼
                      CDN
                /      |       \
             Atlanta   NYC     London
                │       │        │
              User    User      User

Popular tracks are cached close to users.

Benefits:

* Lower latency

* Reduced origin traffic

* Global scalability

* Lower backend load

* Better availability

If the requested chunk isn't cached:

User
 ↓
CDN Edge
 ↓
Cache MISS
 ↓
Origin/Object Storage
 ↓
CDN caches chunk
 ↓
User

Subsequent users receive the cached copy.

--------------------------------------------------------------------------------

10. DEEP DIVE #2: RECOMMENDATION SYSTEM

This is where your answer becomes much stronger than a generic streaming design.

Tell the interviewer:

> “I would separate recommendation generation into candidate generation and
> ranking.”

Architecture:

Listening Events
                          │
                          ▼
                        Kafka
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
        Batch Processing        Stream Processing
              │                       │
              └───────────┬───────────┘
                          ▼
                    Feature Store
                          │
                          ▼
                Candidate Generation
                          │
                   ~1000 candidates
                          │
                          ▼
                       Ranker
                          │
                    ~30-50 tracks
                          │
                          ▼
                 Recommendation API
                          │
                          ▼
                      User App

--------------------------------------------------------------------------------

11. CANDIDATE GENERATION

We cannot rank Spotify's entire catalog for every request.

Suppose there are 100M tracks.

Don't run:

User × 100,000,000 tracks

Instead retrieve perhaps 1,000 promising tracks.

Candidates can come from multiple sources.

COLLABORATIVE FILTERING

Users who listened to similar music also listened to X.

Example:

Atharva listens to:
A
B
C

Users with similar behavior listen to:
A
B
C
D
E

Recommend:
D
E

--------------------------------------------------------------------------------

CONTENT-BASED RECOMMENDATIONS

Analyze attributes such as:

Genre
Artist
Language
Tempo
Mood
Audio characteristics

If someone frequently listens to Indian classical/devotional music, the system
can retrieve tracks with similar characteristics.

--------------------------------------------------------------------------------

EMBEDDINGS

Represent users and songs as vectors.

User embedding

[0.81, 0.12, 0.43, ...]

Song embedding

[0.79, 0.15, 0.39, ...]

Similar vectors imply potential relevance.

Use approximate nearest-neighbor search:

User vector
    ↓
Vector index
    ↓
Nearest tracks
    ↓
Candidate songs

This avoids comparing against every song.

--------------------------------------------------------------------------------

12. RANKING

Now perhaps we have:

1000 candidates

The ranking model predicts things such as:

P(play)
P(skip)
P(like)
P(save)
P(complete)

Features could include:

USER FEATURES

favorite genres
recent listening
favorite artists
time of day
historical skips

TRACK FEATURES

genre
artist
popularity
release age
audio characteristics

CONTEXT

device
time
location/country
network
current session
previous tracks

The ranking system outputs:

1000 candidates
       ↓
Ranking model
       ↓
Top 30

--------------------------------------------------------------------------------

13. FEEDBACK LOOP

This is crucial.

Suppose the recommendation service recommends Track X.

User:

plays 5 seconds
     ↓
skips

That's a negative signal.

Another song:

plays entire song
      +
likes
      +
adds to playlist

Strong positive signal.

Events go through:

Client
 ↓
Event Collector
 ↓
Kafka
 ↓
Stream Processing
 ↓
Feature Store
 ↓
Recommendation System

Therefore recommendations gradually adapt.

--------------------------------------------------------------------------------

14. BATCH + REAL-TIME RECOMMENDATIONS

Explain the difference.

BATCH

Periodically calculate:

* long-term user embeddings

* genre preferences

* artist affinity

* collaborative filtering

* historical behavior

Maybe every few hours/day.

REAL-TIME

Update session-level preferences immediately.

For example:

Normally you listen to:

Bollywood
EDM
Pop

But tonight you start playing:

Meditation
Meditation
Meditation

The system should recognize the current session intent instead of blindly
relying on your lifetime history.

So:

Long-term profile
       +
Real-time session signals
       ↓
Recommendation model

That's a very good interview point.

--------------------------------------------------------------------------------

15. SEARCH ARCHITECTURE

Don't run:

SELECT *
FROM tracks
WHERE title LIKE '%weeknd%'

against the primary database at massive scale.

Instead:

Metadata DB
      │
      ▼
Indexing Pipeline
      │
      ▼
Search Cluster

User request:

"week"
   ↓
Search Service
   ↓
Search Index
   ↓
Candidates
   ↓
Ranking
   ↓
Results

Search can support:

* typo tolerance

* prefix search

* artist matching

* track matching

* popularity ranking

* personalization

--------------------------------------------------------------------------------

16. CACHING

Use caching aggressively.

For example:

Client
 ↓
API Gateway
 ↓
Redis
 ↓ cache miss
Service
 ↓
Database

Cache:

* track metadata

* artist information

* album metadata

* popular playlists

* recommendation results for short periods

* session information

Audio itself belongs primarily in the CDN cache, not Redis.

That's an important distinction.

--------------------------------------------------------------------------------

17. EVENT ARCHITECTURE

Don't synchronously process every listening event.

Bad:

User plays song
      ↓
API
      ↓
Update recommendations
      ↓
Update analytics
      ↓
Update history
      ↓
Update royalty system
      ↓
Response

Too much coupling.

Better:

User Event
    ↓
Event Collector
    ↓
Kafka
    │
    ├──► Recommendation Consumer
    │
    ├──► Analytics Consumer
    │
    ├──► History Consumer
    │
    └──► Royalty/Reporting Consumer

Now services can scale independently.

--------------------------------------------------------------------------------

18. RELIABILITY

Suppose recommendation service goes down.

Should music stop?

No.

Recommendations are not part of the critical playback path.

Design graceful degradation:

Recommendation service unavailable
              ↓
Use cached recommendations
              ↓
or
              ↓
Popular/trending tracks

Similarly, playback should have minimal dependencies.

This is an excellent design principle to explicitly state:

> “I want the playback critical path to have as few synchronous dependencies as
> possible.”

--------------------------------------------------------------------------------

19. MULTI-REGION ARCHITECTURE

At large scale:

Global DNS
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
          US Region             EU Region
              │                     │
        API Services           API Services
              │                     │
          Databases              Databases

Object Storage
                          │
                          ▼
                    Global CDN

Users are routed to nearby healthy regions.

Discuss:

* replication

* regional failover

* data residency

* eventual consistency

* CDN availability

--------------------------------------------------------------------------------

20. HOT SONGS / CELEBRITY RELEASE PROBLEM

Interviewer may ask:

> “Taylor Swift releases a new album and 50 million users immediately play it.
> What happens?”

Answer:

CDN solves much of this.

50M users
   ↓
CDN edges
   ↓
cached chunks

Rather than:

50M users
   ↓
Origin storage

You can also:

* pre-warm CDN caches

* replicate assets globally

* use request coalescing

* autoscale metadata/playback services

* cache track metadata

* apply rate limiting where appropriate

--------------------------------------------------------------------------------

21. PLAYLIST CONCURRENCY

Interviewer could ask:

> “What if I edit my playlist from my phone and laptop simultaneously?”

Now discuss:

versioning
optimistic concurrency control

Example:

Playlist version = 17

Phone updates version 17
→ version 18

Laptop tries updating version 17
→ conflict

Depending on product requirements, either reject/retry or merge operations.

This shows that you understand consistency beyond buzzwords.

--------------------------------------------------------------------------------

22. CAP / CONSISTENCY DISCUSSION

Don't randomly say “CAP theorem.”

Connect it to requirements.

For playlists:

> “Slight propagation delay across devices may be acceptable, so I can favor
> availability with eventual convergence for many operations.”

For listening history:

> “Eventual consistency is fine.”

For recommendations:

> “Definitely eventual consistency.”

For account/subscription authorization:

> “I'd want stronger consistency because incorrect entitlement decisions have
> business/security implications.”

That's much stronger than saying “I'll use eventual consistency everywhere.”

--------------------------------------------------------------------------------

23. SECURITY

Briefly mention:

OAuth/session tokens
TLS
signed CDN URLs
short-lived playback tokens
rate limiting
encryption at rest
DRM/content protection
regional licensing checks

The signed URL matters because otherwise someone could copy:

cdn.com/song123

and distribute it.

Instead:

cdn.com/song123?token=XYZ&expires=...

The URL expires.

--------------------------------------------------------------------------------

24. OBSERVABILITY

A senior-level answer should include this.

Monitor:

Playback startup latency
Buffering ratio
Playback failures
API p95/p99 latency
CDN cache hit ratio
Recommendation CTR
Skip rate
Completion rate
Search latency
Kafka consumer lag
Error rate
Regional availability

For a music product, time-to-first-audio and buffering rate are especially
important.

--------------------------------------------------------------------------------

25. COMPLETE ARCHITECTURE TO DRAW

Near the end, your whiteboard could look like:

USERS
                              │
                              ▼
                     ┌────────────────┐
                     │ Global DNS / LB│
                     └───────┬────────┘
                             │
                             ▼
                       API Gateway
                             │
       ┌──────────────┬──────┼──────────┬───────────────┐
       │              │      │          │               │
       ▼              ▼      ▼          ▼               ▼
     User          Search  Playlist   Playback     Recommendation
    Service        Service  Service    Service         Service
       │              │      │          │               │
       ▼              ▼      ▼          │               ▼
     SQL DB        Search   DB/Cache     │          Feature Store
                   Index                │               │
                                        │          Vector Index
                                        │
                                        ▼
                                  Signed URL
                                        │
                                        ▼
Client ◄─────────────────────────────── CDN
                                        │
                                        ▼
                                  Object Storage

USER EVENTS
                              │
                              ▼
                       Event Collector
                              │
                              ▼
                            Kafka
                              │
             ┌────────────────┼────────────────┐
             ▼                ▼                ▼
         History         Analytics       ML Pipeline
                                               │
                                      ┌────────┴────────┐
                                      ▼                 ▼
                                Batch Training    Stream Features
                                      │                 │
                                      └────────┬────────┘
                                               ▼
                                         Feature Store
                                               │
                                               ▼
                                     Candidate Generation
                                               │
                                               ▼
                                             Ranker
                                               │
                                               ▼
                                      Recommendations

--------------------------------------------------------------------------------

HOW TO ACTUALLY SPEAK DURING THE INTERVIEW

Your flow should sound like this:

> “I'll start by defining the scope. The core functionality is search, playback,
> playlists, listening history and personalized recommendations. I'll optimize
> primarily for high availability, low playback latency and global scale.
> 
> Given hundreds of millions of users and potentially tens of petabytes of daily
> audio delivery, I don't want audio flowing through application servers. I'll
> store encoded audio in object storage and distribute chunks through a global
> CDN.
> 
> The client calls the playback service, which authenticates the user, checks
> entitlement and regional availability, and returns a short-lived signed
> streaming URL or manifest. The client then downloads audio chunks directly
> from the CDN.
> 
> On the metadata side, I'll separate user, playlist, search and playback
> services so they can scale independently. Track metadata can live in a durable
> database, while search uses a dedicated inverted index and frequently accessed
> metadata is cached.
> 
> Every play, skip, like, save and search generates an asynchronous event. I'll
> publish those events to Kafka so listening history, analytics and
> recommendations don't increase playback latency.
> 
> For recommendations, I'll use a two-stage architecture. Candidate generation
> retrieves perhaps a thousand promising tracks using collaborative filtering,
> content similarity and embedding-based nearest-neighbor retrieval. A ranking
> model then scores those candidates using user, track and contextual features
> and returns the top results.
> 
> I'll combine batch-computed long-term preferences with real-time session
> signals so recommendations can respond to what the user is listening to right
> now.
> 
> Finally, I'd deploy API services across multiple regions, put audio behind a
> global CDN, replicate critical data, use graceful degradation if
> recommendation systems fail, and monitor playback startup latency, buffering,
> CDN hit ratio and recommendation quality.”

That alone is a very solid interview answer.

THE MENTAL MODEL TO MEMORIZE

Don't memorize 25 boxes. Memorize this:

Spotify = 3 major systems

1. CONTROL PLANE
   User + Search + Playlist + Playback APIs
                  │
                  ▼
2. STREAMING PLANE
   Object Storage → CDN → Client
                  │
                  ▼
3. INTELLIGENCE PLANE
   Events → Kafka → Features → Candidates → Ranking

Then remember the core design principle:

Metadata goes through APIs. Audio goes through CDN. User behavior goes through
an event stream. Recommendations use candidate generation + ranking.

Design a music streaming and recommendation service like Spotify.

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Practice More Questions