Requirements

Functional Requirements:

• Allow user to stream music - pause, play, skip
• Allow user to manage playlists - create, edit, delete
• Allow users to search for songs, artists, and albums
• Allow users to like songs
• Personalized recommendations (home feed)
• Allow offline music streaming

Non-Functional Requirements:

• Highly scalable: support ~50M DAU and ~1B daily streams
• Highly available: 99.9% uptime for playback
• Strong consistency for billing/subscription
• Eventual consistency for playlists, home feed, and likes
• High streaming throughput: <300ms latency for audio start
• <200ms latency for search

Capacity Estimation

• 500M users
• 50M DAU
• 100M songs library
• Avg ~5MB song size (compressed)

Storage: 100M x 5MB = 500TB raw data

Streaming bandwidth:

• 50M dau
• 20 songs/day/user: ~3min per song
• ~1B streams/day
• Bandwidht per stream : 160kbps
• Total bandwidth: ~180-250 gbps sustained global traffic

API Design

Playlists:

POST /playlists

GET /playlists/{id}

PUT /playlists -> update/soft-delete playlist

req - {

status : 'InActive'

}

POST /playlists/{id}/song -> Add song

PUT /playlists/{id}/song -> soft-delete song from playlist

Playback:

GET /songs/{id}

• returns song metadata which includes a manifest file url
• Manifest file contains: singed CDN url, bitrate options etc

Search:

GET /search?q=XYZ?cursor=id

-> returns: songs, artists, albums matching the query

GET /home-feed

-> returns users's personalized home feed (songs)

Like songs:

POST /songs/{id}/like

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - Applied using token bucket per IP to prevent fraudulent or bot views
• Request routing

Load Balancer

Distributes traffic across multiple instances of all services to improve scalability and availability.

User Service/Playlist Service -> CRUD operations for both user and playlists

Streaming service:

Responsibilities

• Recieves song streaming request
• Fetches that song's metadata via redis
• Uses Cassandra as fallback if cache miss from redis
• Returns back metadata thja contains the manifest file url for streaming options

Search Service

Responsibilities

• Recieves a search query
• Normalizes the query in a standard format
• Fetches top K song ids from in elastic search index
• Enrich the song metadata from redis/cassandra
• returns ~20 records

ElasticSearcgh

• Inverted index
• Stores
  • Keyword ->list of songs, artists, albums

Event collection service

Responsibilties:

• Each user event such as pause, play, skip, like all comes to this service
• The service is validates and emits the event to kafka

Kafka:

• Event backbone
• Uses song id as partition key for all events
• Gurantees at least once delivery

Flink:

• Consumes events from kafka
• Updates event-related data in-memory
  • eg: userId123: {rockAffinity: 0.7, likeRate:0.6} etc
• Flushes the data aggreated to feature store

Feature store / ML Model:

• Part of personalized recommednation generation
• Feature store acts as a centralized data, ML model consumes those data periodically and trains the recommendation model.

Feed/Recommendation Service:

• Responsioble for recommednation generation:
  • uses ML model to check user preferences computed via user events
  • Using user prefeneces generates top k ranked recommended song
  • Stores in redis. Cassandra as fallback
• Also receives get home feed request
• Fetches home feed of user from redis (cassandra as fallback) and returns it

Redis:

• Caching layer
• Stores:
  • Hot/Trending Song metadata -> LRU -> TTL ~ 24 hrs
    • eg: song123:{title, cdn url, genre, duration}
  • User home feed - already ranked
    • eg: UserId :{song123,song456,song789}

Database Design

We use a hybrid SQL (PostgreSQL) + NoSQL (Cassandra) architecture.

• SQL is used for strongly consistent relational data like Users, PlayLists, PlayListSongs
• NoSQL (Cassandra) is used for high-scale data like Songs, Artists, Albums, due to its horizontal scalability and high write throughput.

Users

id

name

email

country (partition key)

Playlist

id

name

user_id (partition key)

status

PlaylistSongs

id

playlistId (partition key)

songId

position

Status

Songs

id

title

artist_id

album_id

duration

genre

-> artist id + album id as partition key

Artists

id

name

status

Albums

id

artist_id

songs[]

released_date

Detailed Component Design

We will now deep dive in the following topics:

handling Streaming traffic with ABR:

-> How to handle ~1B streaming requests daily

-> We never stream from backend, Instead of returning the entire song for playback whcih would be too heavy processing, we utilize ABR streaming + CDN, how does it work?

ABR streaming:

• Our streaming service returns back song medata, this metadata contains a manifest url
• Client reads the manifest file from url
• The manifest file has:
  • pre signed cdn urls for song chunks
  • ABR options
• Client then fetcehs song chunks via the cdn urls from CDN
• The songs are divided in multiple chunks, so client request chunk of where user is currently liseining
• Each chunk ~10sec
• So client preloads next chunk too, hence we never load entire song just ~10-20 sec of song is loaded at a time.
• Even when user skips ahead, the client requests chunks of that skip ahead timestamp

CDN

• Helps in reducing backend load
• We use multi-region CDN : meaning user connects to the nearest edge CDN
• Hence it can handle millions of concurretn streams
• If a song is not in CDN, then CDN fallbacks to Object storage where the actual song data, manifest files are stored

Recommendation Pipelein/generation

-> The most service dense feature of the system

-> Services like Event collection, kafka, feed/recommendation service, FLink, ML model and feature store work togetehr for the personlzied home feed generation.

How does the it work?

• All user events lands in event collection service
• The service pushnes it to kafka
• Flink consumes those event from kakfa
• Flink updates its in memory data to reflect the event
  • eg: if a song play event came in for genre: rock
    • flink aggrates event -> user123 -> rockPlays = 101
    • Flink also computes user pref

• Flink periodically flushes the data to the feature store
• The data from featrue store is then fed to ML model for training
• Once ml model is trained a hourly job from recommedation service runs
• This job, checks trained ML model.
• fetches ~20-30 songs from each of users fav genre (determined from genre affinity, like and skip rate)
• Ranks those top k songs, again using the user pref from ML model as a scoring factor
• Stores those ranked songs as a user feed in Redis, as well as in Cassandra as a fallback.

Failure Handling

• Redis crashes
  • For both metadata and feed -> cassandra acts as a fallback
  • Metadad cache is then rebuilt lazily, while home feed is rebuild via nightly/daily job or if required then triggered Adhoc
• Kakfa failure
  • Kafka gurantees at least once delivery -> so all events are retained
  • If kafka crashes, the new instance will pick up the event from last checkpoint
• Flink failure
  • Flink periodically(10-30sec) stores checkpoints to object storage
  • When it crashes, new insteace picks up and restores to last checkpoint

Scaling strategies:

• horizontal scaling services
• partition users by region
• shard playlists by user_id
• multi-region replication