OneNoughtOne
0/319
Loading content...
Read aloud is unavailable in this browser.
Spotify is more than a music player—it's a distributed system that streams over 100 million songs to 615+ million users across 180+ markets worldwide. Every day, users generate billions of streams, create millions of playlists, and interact with an ever-growing catalog of audio content. Behind the simple act of pressing 'play' lies one of the most sophisticated content delivery systems ever built.
Designing a system like Spotify requires balancing seemingly contradictory requirements: instant playback with global reach, personalized experiences with massive scale, and seamless streaming with complex licensing constraints. This case study explores how to architect such a system from first principles.
By the end of this page, you will understand how to gather and analyze requirements for a music streaming platform, distinguish between functional and non-functional requirements, and establish the scope and scale that will drive every architectural decision throughout this design.
Before diving into architecture, we must deeply understand what we're building. A music streaming platform operates at the intersection of content delivery, personalization, social features, and licensing compliance. Each dimension introduces unique challenges that cascade through every layer of the system.
The core problem statement:
Design a system that allows users to discover, stream, and organize music from a catalog of 100+ million tracks, with sub-second playback latency, support for hundreds of millions of concurrent users, and compliance with complex licensing agreements across 180+ countries.
Let's break this down systematically.
We'll focus on the core streaming and playlist functionality first, then progressively address recommendations, offline mode, and licensing in subsequent pages. This mirrors how you would approach a system design interview—start with the core, then expand based on time and interviewer interest.
Understanding scale is critical—it determines whether your design works in production or collapses under load. Let's quantify the scale we're designing for:
User Scale:
Content Scale:
Usage Patterns:
| Metric | Calculation | Result | Implications |
|---|---|---|---|
| Daily Streams | 615M users × 50% DAU × 30 songs/day | ~9 billion streams/day | Need massively parallel streaming infrastructure |
| Peak QPS for Streams | 9B / 86,400 × peak multiplier (3x) | ~312,500 streams/second | Requires distributed architecture across regions |
| Storage (Original) | 100M tracks × 50MB avg (lossless) | ~5 PB raw storage | Object storage with efficient encoding |
| Storage (Encoded) | 100M × 5 qualities × 10MB avg | ~5 PB encoded | Plus redundancy = 15+ PB total |
| Metadata Volume | 100M tracks × 5KB metadata avg | ~500 GB | Fits in memory with sharding |
| Playlist Data | 4B playlists × 100 tracks × 50 bytes | ~20 TB playlist data | Sharded database cluster |
At hundreds of thousands of streams per second, every architectural decision compounds. A 1ms latency increase affects 300+ million streams daily. A 1% error rate means 90 million failed streams per day. These numbers drive our obsession with efficiency and reliability.
The core functionality of any music streaming platform is, of course, streaming audio. But this simple concept expands into numerous specific requirements when we examine it closely.
Core Streaming Requirements:
Playback Control Requirements:
When gathering streaming requirements in an interview, always ask about: quality tiers, network conditions to handle, mobile vs. desktop differences, and whether gapless/crossfade is needed. These determine encoding strategy and buffer management.
Playlists are the organizational backbone of music streaming. They represent how users curate, organize, and share their music. Spotify hosts over 4 billion playlists, making playlist management a core architectural challenge.
Playlist Management Requirements:
User Library Requirements:
Beyond playlists, users maintain a personal library of saved content:
| Feature | Scale | Challenge | Approach |
|---|---|---|---|
| Total Playlists | 4+ billion | Storage and indexing | Sharded databases with playlist_id partitioning |
| Tracks per Playlist | Up to 10,000 | Large playlist rendering | Virtualized lists, paginated fetches |
| Collaborative Edits | Concurrent writes | Conflict resolution | CRDT-like merge strategies |
| Playlist Follows | Millions per popular playlist | Fan-out updates | Eventual consistency, notifications batching |
| Search within Playlist | Large playlists | Client-side performance | Server-side search for 500+ tracks |
Playlists seem simple but involve complex data relationships: owner, collaborators, followers, track ordering, track metadata snapshots (what if a track is later removed from catalog?), and version history for rollback. We'll design this data model carefully in the architecture section.
Users need to find music, whether they know exactly what they want or are exploring for something new. Discovery encompasses both explicit search and algorithmic recommendations.
Search Requirements:
Content Browsing:
Search is explicit intent—the user knows what they want. Recommendations address implicit discovery—helping users find music they'll love but don't know about yet. Both require different architectural approaches: search needs full-text indexing, while recommendations need ML pipelines and feature stores.
Non-functional requirements define how well the system must perform, not what it does. For a music streaming platform, these requirements are often more challenging than the functional ones.
Performance Requirements:
| Metric | Target | Rationale |
|---|---|---|
| Time to First Byte | <200ms globally | Users expect instant playback |
| Buffering Ratio | <1% of playback time | Buffering destroys listening experience |
| Search Latency | <100ms for typeahead | Results must appear while typing |
| API Latency (P99) | <500ms | UI responsiveness depends on quick API calls |
| Playlist Load Time | <300ms for 1000 tracks | Large playlists must render quickly |
| Cold Start Time | <3s on mobile | App must be usable within seconds |
Scalability Requirements:
Availability & Reliability:
A music streaming failure is immediately perceived—unlike background sync or email, users experience disruption in real-time. A 1-minute global outage during peak hours affects 100+ million active listeners. This drives extreme reliability requirements.
Security Requirements:
Compliance Requirements:
Music streaming is heavily regulated through licensing agreements:
Operational Requirements:
In a system design interview, you cannot address every requirement in depth. Strategic prioritization demonstrates maturity. Here's how to think about priorities for a music streaming MVP:
P0 (Must Have) — Without these, no viable product:
P1 (Important) — Needed for competitive product:
P2 (Nice to Have) — Enhancements for mature product:
In an interview, explicitly state your prioritization: 'I'll focus on P0 requirements first—streaming, search, and basic playlists. Once we have a solid architecture for those, we can discuss how to add recommendations and offline mode.' This shows maturity and time management.
We've established a comprehensive understanding of what we're building. Let's consolidate the key requirements that will drive our architecture:
| Category | Key Requirements | Priority |
|---|---|---|
| Streaming | Instant playback (<200ms), adaptive quality, gapless playback | P0 |
| Playlists | Create/manage playlists, add/remove/reorder tracks, sharing | P0 |
| Search | Multi-entity search with <100ms typeahead latency | P0 |
| Library | Save songs, albums, artists; sync across devices | P0/P1 |
| Recommendations | Personalized discovery based on listening history | P1 |
| Offline Mode | Download and play without network connectivity | P1 |
| Performance | <200ms time to first byte, <1% buffering ratio | P0 |
| Availability | 99.95% uptime, graceful degradation | P0 |
| Compliance | Geo-restrictions, royalty tracking, DRM | P0 |
What's next:
With requirements established, we'll move into the architectural design. The next page covers Audio Streaming Architecture—how we encode, store, distribute, and deliver audio content to hundreds of millions of users with sub-second latency. This is the technical heart of the system.
You now have a comprehensive understanding of the requirements for designing a music streaming platform like Spotify. We've covered functional requirements (streaming, playlists, search), non-functional requirements (performance, scale, reliability), and established clear priorities for MVP development. Next, we dive into the architecture that makes streaming possible at global scale.