Amazon VO Interview Question: Design a Playlist Service | System Design

Design a new service for users to create playlists and store songs in them.

Functional requirements

• Users can create any number of playlists.
• Users can add songs to a playlist.
• Another team has already created some self-hosted playlists.
• Support 3 types of playlists:
• platform-created playlists
• user-created playlists
• personalized playlists generated based on user preferences

Questions

• Do we have a limit on the number of playlists or number of songs per playlist?
• Do we need to support things like downloading songs within a playlist, or is just tracking the playlist content enough?

Non-functional requirements

Capacity estimation question:

1. What is the expected number of write (change playlist) and read (view playlist) requests per second?

80 million daily active users. Assume each user makes on average 1 write request per day. Then we have about 8 × 10^7 requests per day. Divide by around 10^5 seconds per day, and we have around thousands of write requests per day.

I think the system is read-heavy, so we might have tens of thousands of read requests.

2. How long do we need to persist playlist setup for, like forever?

So the non-functional requirements can be:

• Scalability: Must support millions of users, each with potentially hundreds of playlists.
• Only allow up to 1000 items per playlist.
• Low latency: Read operations (get playlist, list songs) should be fast (<100ms).
• Since this is a read-heavy system, I would say eventual consistency is enough. In terms of CAP theorem, we would prefer availability over consistency. For example, if a user modifies a playlist by adding a new song, the iPad or computer on the same account might get some delay, like the song is updated after a second or something, so not immediately consistent but will sync eventually.

API design

1. API to create a new playlist

POST /api/v1/playlists
Body:
{"name": "some playlist name", "type": "USER_CREATED"}

2. API to add a new song to a playlist

POST /api/v1/playlists/{playlist_id}/songs
Body:
{"song_id": "SONG_001"}

3. API to delete a playlist or delete a song from a playlist

DELETE /api/v1/playlists/{playlist_id}/songs/{song_id}
DELETE /api/v1/playlists/{playlist_id}

4. Get all playlists of a customer

GET /api/v1/playlists?user_id=123

5. Get playlist content

GET /api/v1/playlists?playlist_id=123

6. Get a specific song

GET /api/v1/playlists/{playlist_id}/songs/{song_id}

To save time, let’s do the high-level design. I will talk about the data schema later.

This is a classic playlist service design problem with a read-heavy workload. The key tradeoff is to keep write APIs simple for creating playlists and adding/removing songs, while making reads fast through a dedicated read service and cache layer. Because immediate consistency is not required, eventual consistency with async cache updates or CDC works well. A scalable storage model can partition by user_id and playlist_id, enforce a per-playlist item limit, and separate playlist metadata from audio file storage so songs can be served efficiently through object storage and CDN.