Skip to content
System Designer

Medium · Media and streaming

Music streaming

People search for songs, build playlists and press play. The audio is the heavy part, and a hit song is played by millions at once. Playback must not stutter, even when part of your system fails. Practise this medium system design problem for free with a Google or GitHub account.

The brief

People search for songs, build playlists and press play. The audio is the heavy part, and a hit song is played by millions at once. Playback must not stutter, even when part of your system fails.

Think of a music service like Spotify.

Users, scale and requirements

Who uses it
1.5 million listeners a month
Audience in plain numbers
1,500,000 people per month
Normal peak
≈ 500 requests per second
Request mix
Stream chunk: 50%; Search: 20%; Read: 20%; Analytics event: 6%; Write: 2%; Sign-in: 2%
Speed for 99 of 100 requests
Stream chunk: ≈ 1,000 ms; Search: ≈ 400 ms; Read: ≈ 350 ms; Write: ≈ 350 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.5%
Data safety
At most 1 minute of writes may be lost.
Monthly budget
≈ $46,000
Data at rest
≈ 60 TB
Where users are
North America: 40%; Europe: 40%; Asia Pacific: 20%
Home region
North America
Waiting deadlines
Stream chunk: 900 seconds; Search: 900 seconds; Read: 900 seconds; Analytics event: 3,600 seconds; Write: 3,600 seconds; Sign-in: 900 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
40% of reads are private; a shared public copy cannot answer them.

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • An average song is about 5 MB (approx.); the game counts 2 MB stream chunks.
  • Playlist edits must show up for the person who made them straight away.

Questions that shape the design

Can the music keep playing if the playlist service is down?

It should. A song that has started must finish even when your database has a bad moment.

Where are the listeners?

Spread across three continents. A listener far from your servers waits longer to start a song.

What happens on a big album release day?

Millions press play on the same few songs within minutes. This is your hottest data of the year.

How good must search be?

Fast and forgiving. People mistype names. Results should arrive in well under half a second.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 10:00 · Hot key

    One item gets a huge share of traffic: a celebrity profile, one product, one merchant.

    Affected share: 35%. Duration: ≈ 3,600 seconds.

  2. 15:00 · Region outage

    A whole cloud region goes down.

    Duration: ≈ 1,800 seconds.

What a strong design has to handle

  • What should still work if your main region goes dark for half an hour?
  • Keep playback independent of discovery and playlist failures.
  • Keeping songs on the CDN with a long cache time makes playback survive almost any outage, but a song taken down for rights reasons needs an explicit purge.
  • A search index is a copy of the catalog. It is fast and forgiving, but it can be a few seconds behind the real catalog.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems