Designing a Music Streaming Platform (like Spotify)

Problem Statement

Design a music streaming platform that allows users to browse, search, create playlists, and stream music seamlessly. The system must handle efficient content delivery across geographies, provide personalized recommendations, manage user interactions (likes, follows, collaborative playlists), and support multiple audio quality tiers. The platform should serve millions of concurrent users with minimal latency while respecting licensing constraints and supporting both free (ad-supported) and premium subscription models.

---

Requirements

Functional Requirements

1. User Registration & Profiles - Sign up/login (email, social OAuth), profile management, listening preferences, subscription tier
2. Browse & Search Music - Search by artist, album, song title, genre, mood, and era; full-text search with autocomplete
3. Create & Manage Playlists - Create, edit, delete, reorder playlists; collaborative playlists with multiple editors
4. Stream Songs - Real-time audio streaming with play, pause, seek, skip; crossfade between tracks
5. Offline Download - Download songs for offline playback (premium); encrypted storage with license expiry
6. Like & Follow - Like songs, follow artists/playlists; feed of new releases from followed artists
7. Recommendations - Personalized daily mixes, discover weekly, radio stations based on seed tracks
8. Recently Played - Listening history with resume capability
9. Queue Management - User queue, auto-queue (up next), shuffle, repeat modes
10. Collaborative Playlists - Multiple users add/remove songs in real-time

Non-Functional Requirements

---

Constraints & Assumptions

• Catalog Size: 100M+ songs, growing by 60K daily
• Audio Quality Tiers: 128kbps (free/mobile), 256kbps (premium standard), 320kbps (premium high)
• Subscription Model: Free tier with ad interruptions every 3-5 songs; premium tier ad-free with offline access
• Licensing & DRM: Songs are DRM-protected; regional availability varies by licensing agreements
• Storage: Average song ~4MB at 128kbps (4 min), ~10MB at 320kbps; total catalog ~500TB+ across all qualities
• Peak Load: Commute hours (7-9 AM, 5-7 PM) see 3x average traffic
• Global Distribution: Users across 180+ countries; CDN with edge nodes in major metros

---

Key Entities & Relationships

Relationships: User creates Playlist (1:N), Playlist contains Song (M:N), Artist releases Album (1:N), Album contains Song (1:N), Song belongs to Genre (M:N), User has PlayHistory (1:N), User has Queue (1:1).

---

ASCII Class Diagram

┌─────────────┐       ┌──────────────┐       ┌─────────────┐
│    User     │       │   Playlist   │       │    Song     │
├─────────────┤       ├──────────────┤       ├─────────────┤
│ userId      │1    N │ playlistId   │M    N │ songId      │
│ name        ├───────┤ name         ├───────┤ title       │
│ email       │creates│ isPublic     │contains│ duration    │
│ subscription│       │ collaborators│       │ audioFiles[]│
│ preferences │       │ songRefs[]   │       │ albumId     │
└──────┬──────┘       └──────────────┘       └──────┬──────┘
       │                                            │
       │ has                                        │ belongs to
       ▼                                            ▼
┌─────────────┐       ┌──────────────┐       ┌─────────────┐
│   Queue     │       │   Artist     │       │   Album     │
├─────────────┤       ├──────────────┤       ├─────────────┤
│ currentIdx  │       │ artistId     │1    N │ albumId     │
│ songs[]     │       │ name         ├───────┤ title       │
│ shuffleOrder│       │ verified     │releases│ releaseDate │
│ repeatMode  │       │ listeners   │       │ coverArt    │
└─────────────┘       └──────────────┘       └─────────────┘

┌─────────────────────────────────────────────────────────────┐
│                  Streaming Components                         │
├─────────────────────────────────────────────────────────────┤
│  ┌───────────┐   ┌──────────────┐   ┌───────────────────┐  │
│  │ CDN Edge  │   │ Transcoder   │   │ StreamSession     │  │
│  │ Cache     │──▶│ Service      │──▶│ Manager           │  │
│  │           │   │ (multi-rate) │   │ (ABR controller)  │  │
│  └───────────┘   └──────────────┘   └───────────────────┘  │
└─────────────────────────────────────────────────────────────┘

---

Streaming Protocols

This is the core technical challenge of a music streaming platform. Understanding streaming protocols is essential for making informed design decisions about latency, quality, and scalability.

Progressive Download

Progressive download is the simplest streaming approach. The client requests the entire audio file via a standard HTTP GET request, and playback begins once enough data has been buffered. This was the dominant approach in early web audio (think early SoundCloud or Bandcamp) before adaptive streaming became standard.

How It Works:

1. Client sends HTTP GET request for the audio file
2. Server responds with the file, streaming bytes sequentially via chunked transfer encoding
3. Client buffers initial bytes (typically 2-5 seconds of audio)
4. Playback begins while download continues in background
5. File is stored in temporary cache; subsequent plays are instant

Buffering Behavior:

• Initial buffer fills before playback starts (cold start delay of 1-3 seconds)
• If playback catches up to downloaded bytes, rebuffering occurs (stall)
• Entire file eventually resides on client (cache-friendly for repeat plays)
• No intelligence about network conditions - downloads at maximum available speed
• Wastes bandwidth if user skips to next song before download completes

Seek Limitations:

• Seeking forward beyond downloaded bytes requires HTTP Range requests
• Server must support Range headers (most modern servers do)
• Seeking backward works instantly from local buffer
• No adaptive quality - committed to single bitrate for entire file duration
• If user is on 128kbps connection requesting 320kbps file, constant buffering with no fallback

Bandwidth Waste Problem: A key issue with progressive download for music streaming is that users frequently skip songs. Studies show ~30% of songs are skipped within the first 30 seconds. With progressive download, you may have already downloaded 50-70% of the file, wasting bandwidth and CDN costs.

Use Case: Suitable for short audio clips, podcast episodes, or preview snippets where simplicity is preferred over adaptability. Not ideal for music streaming at scale due to lack of adaptive bitrate and bandwidth waste on skipped tracks.

HTTP Live Streaming (HLS)

HLS, developed by Apple, is the most widely supported adaptive streaming protocol. It breaks audio into small segments and uses manifest files to coordinate delivery.

Core Components:

• Master Playlist (.m3u8): Lists available quality variants
• Media Playlist (.m3u8): Lists segments for a specific quality level
• Segments (.ts or .aac): Small audio chunks (typically 2-10 seconds each)

How It Works:

┌──────────┐         ┌──────────────┐         ┌──────────┐
│  Client  │         │  CDN / Edge  │         │  Origin  │
│ (Player) │         │    Server    │         │  Server  │
└────┬─────┘         └──────┬───────┘         └────┬─────┘
     │                      │                      │
     │  GET master.m3u8     │                      │
     │─────────────────────▶│                      │
     │  (quality variants)  │                      │
     │◀─────────────────────│                      │
     │                      │                      │
     │  GET 256kbps.m3u8    │                      │
     │─────────────────────▶│  (cache miss)        │
     │                      │─────────────────────▶│
     │  (segment list)      │◀─────────────────────│
     │◀─────────────────────│                      │
     │                      │                      │
     │  GET segment_001.aac │                      │
     │─────────────────────▶│  (cache hit!)        │
     │  [audio data]        │                      │
     │◀─────────────────────│                      │
     │                      │                      │
     │  GET segment_002.aac │                      │
     │─────────────────────▶│                      │
     │  [audio data]        │                      │
     │◀─────────────────────│                      │
     │         ...          │                      │

Master Playlist Example:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=128000,CODECS="mp4a.40.2"
quality_128/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=256000,CODECS="mp4a.40.2"
quality_256/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=320000,CODECS="mp4a.40.2"
quality_320/playlist.m3u8

Adaptive Bitrate in HLS:

• Client monitors download speed of each segment
• If bandwidth drops, client switches to lower quality variant on next segment boundary
• Seamless quality transitions at segment boundaries (no interruption)

Advantages: Universal iOS/macOS support, CDN-friendly (standard HTTP), mature ecosystem, supports DRM (FairPlay).

DASH (Dynamic Adaptive Streaming over HTTP)

DASH (Dynamic Adaptive Streaming over HTTP) is an international standard (ISO/IEC 23009-1) that provides vendor-neutral adaptive streaming, similar in concept to HLS but with different manifest format and more flexibility.

Core Components:

• MPD (Media Presentation Description): XML manifest describing available content
• Adaptation Sets: Groups of representations (e.g., different bitrates of same content)
• Representations: Specific quality/bitrate versions
• Segments: Individual chunks of media data

MPD Structure:

<MPD type="static" mediaPresentationDuration="PT3M45S">
  <Period>
    <AdaptationSet mimeType="audio/mp4" codecs="mp4a.40.2">
      <Representation id="1" bandwidth="128000">
        <SegmentTemplate media="seg_128_$Number$.m4s"
                         initialization="init_128.mp4"
                         duration="4000" timescale="1000"/>
      </Representation>
      <Representation id="2" bandwidth="256000">
        <SegmentTemplate media="seg_256_$Number$.m4s"
                         initialization="init_256.mp4"
                         duration="4000" timescale="1000"/>
      </Representation>
      <Representation id="3" bandwidth="320000">
        <SegmentTemplate media="seg_320_$Number$.m4s"
                         initialization="init_320.mp4"
                         duration="4000" timescale="1000"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Comparison with HLS:

Adaptive Bitrate Streaming

Adaptive Bitrate (ABR) streaming is the intelligence layer that decides which quality level to request for each segment. This is critical for maintaining uninterrupted playback across varying network conditions.

How Quality Switching Works:

1. Player downloads a segment and measures throughput
2. ABR algorithm evaluates current conditions
3. Next segment is requested at appropriate quality level
4. Switch happens at segment boundary - no audible glitch

Buffer-Based Algorithm (BBA):

• Decisions based solely on current buffer level
• Low buffer → request lowest quality (prioritize filling buffer)
• High buffer → request highest quality (maximize experience)
• Simple, reactive, works well for steady-state playback
• Risk: oscillation between qualities if buffer hovers near thresholds

Buffer Level:    [====|==========|==========|====]
                  0s    5s         15s        30s
Quality:         LOW    MEDIUM     HIGH       MAX
                 (panic) (cautious) (comfort)  (full)

Throughput-Based Algorithm:

• Estimates available bandwidth from recent segment downloads
• Selects highest quality whose bitrate is below estimated throughput (with safety margin)
• More proactive than buffer-based
• Risk: bandwidth estimation can be noisy on mobile networks

Hybrid Approach (used in practice):

• Combine buffer level AND throughput estimation
• Use throughput for steady-state decisions
• Fall back to buffer-based logic when buffer is critically low
• Add startup-specific logic (start low, ramp up quickly)
• Spotify uses a variant called "Bandwidth Estimation with Buffer Awareness" (BEBA)

Startup Optimization for Music: Music streaming has a unique advantage over video: audio files are small. A 4-minute song at 320kbps is only ~10MB. This means:

• Aggressive initial buffering is feasible (buffer entire song in seconds on fast connections)
• Quality ramp-up can be faster than video (less data per segment)
• Pre-fetching the next song in queue while current song plays eliminates gaps between tracks
• Crossfade implementation requires buffering two streams simultaneously during transition

Protocol Comparison Table

Recommendation for Music Streaming: Use HLS as primary protocol (iOS dominance in music market) with DASH for Android/web. Fall back to progressive download for legacy clients. Avoid WebSocket for on-demand music - it doesn't leverage CDN caching.

---

Design Decisions & Trade-offs

Audio Format and Quality Tiers

Decision: Use OGG Vorbis (like Spotify) for desktop/web, AAC for mobile. OGG offers better quality-per-bit than MP3 and is royalty-free. AAC has universal hardware decoder support on mobile devices.

Streaming Approach

Decision: Adaptive streaming (HLS + DASH) over progressive download.

• Trade-off: Higher infrastructure complexity (transcoding pipeline, segment storage) but dramatically better user experience on variable networks. Storage cost increases ~3x (storing 3 quality tiers per song).

Caching Strategy

• L1 Cache (Client): Recently played songs cached locally (LRU, 1GB limit)
• L2 Cache (CDN Edge): Top 1% of songs (by play count) pre-warmed at all edge nodes
• L3 Cache (Regional): Top 10% cached at regional PoPs
• Origin: Full catalog stored in object storage (S3/GCS)

Trade-off: Aggressive edge caching reduces origin load by 95%+ but increases CDN costs. The long-tail of music (80% of catalog played rarely) is served from origin with higher latency.

Recommendation Algorithm

• Collaborative Filtering: "Users who liked X also liked Y" - good for discovery
• Content-Based: Audio features (tempo, key, energy) similarity - good for radio stations
• Hybrid: Combine both with contextual signals (time of day, device, activity)

Trade-off: Collaborative filtering has cold-start problem for new users/songs. Content-based requires audio analysis pipeline. Hybrid is most effective but computationally expensive.

Playlist Storage

Decision: Store song references (songId) in playlists, not copies of metadata.

• Trade-off: If a song is removed from platform, playlist shows "unavailable" rather than stale metadata. Requires join at read time but ensures consistency.

Offline Mode

• Songs encrypted with device-specific key (AES-256)
• License checked every 30 days (requires brief online connection)
• Downloaded songs removed if subscription lapses
• Trade-off: Strict DRM protects rights holders but adds complexity and can frustrate users with intermittent connectivity.

---

Design Patterns Used

Strategy Pattern in Detail - Quality Selection: The streaming quality selector implements a common interface (selectQuality(networkConditions, userPreferences) → QualityTier). Concrete strategies include: AutoQualityStrategy (ABR-based), DataSaverStrategy (always lowest), HighFidelityStrategy (always highest, buffer more). Users choose their preference in settings, and the player swaps strategy implementations at runtime.

State Pattern in Detail - Player States: Each state encapsulates valid transitions and behaviors. For example, calling seek() in LOADING state queues the seek for after load completes, while calling seek() in PLAYING state triggers immediate segment fetch. The BUFFERING state automatically transitions to PLAYING when buffer threshold is met, without external intervention.

---

Audio Player State Machine

                         ┌─────────────────────────────────┐
                         │          song selected           │
                         ▼                                  │
┌────────┐  play()  ┌─────────┐  buffered  ┌─────────┐   │
│  IDLE  │─────────▶│ LOADING │───────────▶│ PLAYING │   │
└────────┘          └─────────┘            └────┬────┘   │
    ▲                    │                      │ │       │
    │                    │ error()               │ │       │
    │                    ▼                      │ │       │
    │               ┌─────────┐                │ │       │
    │               │  ERROR  │                │ │       │
    │               └─────────┘                │ │       │
    │                                          │ │       │
    │  stop()       ┌─────────┐    pause()     │ │       │
    │◀──────────────│ STOPPED │◀───────────────┘ │       │
    │               └─────────┘                  │       │
    │                    ▲                       │       │
    │                    │ stop()                │       │
    │                    │                       │       │
    │               ┌─────────┐   pause()       │       │
    │               │ PAUSED  │◀────────────────┘       │
    │               └────┬────┘                         │
    │                    │ resume()                      │
    │                    ▼                               │
    │               ┌───────────┐  buffered             │
    │               │ BUFFERING │───────────────────────┘
    │               └───────────┘
    │                    │
    │    network_fail()  │
    └────────────────────┘

Key Transitions:

• IDLE → LOADING: User selects a song; fetch manifest and first segments
• LOADING → PLAYING: Sufficient buffer accumulated (typically 2-3 segments)
• PLAYING → BUFFERING: Buffer depleted due to slow network; ABR may downshift quality
• BUFFERING → PLAYING: Buffer refilled; playback resumes seamlessly
• PLAYING → PAUSED: User pauses; buffer continues filling opportunistically
• Any → STOPPED: User stops or song ends; release resources

---

Edge Cases

---

Extensibility Points

1. Podcasts - Same streaming infrastructure; different metadata model (episodes, shows, RSS ingestion); chapter markers; variable speed playback
2. Live Audio (Radio) - Switch from static to live HLS manifests; lower segment duration (1-2s); real-time encoding pipeline
3. Social Features - "Listening together" sessions via shared queue over WebSocket; activity feed; shared playlists
4. Lyrics Display - Synchronized lyrics (LRC format) with timestamp alignment; karaoke mode; lyrics search
5. Music Videos - Add video adaptation sets to DASH/HLS manifests; video CDN tier; picture-in-picture support
6. Artist Analytics - Real-time play counts; geographic listener distribution; playlist inclusion tracking; revenue dashboards
7. Concert Tickets - Integration with ticketing APIs; "on tour" badges; location-based event recommendations

---

Interview Follow-ups

Q1: How would you handle adaptive bitrate switching?

Answer: Implement a hybrid ABR controller that combines throughput estimation with buffer occupancy. During steady-state playback, use exponentially weighted moving average (EWMA) of recent segment download speeds to estimate bandwidth. Select the highest quality tier whose bitrate is ≤ 80% of estimated throughput (safety margin). When buffer drops below 5 seconds, override to lowest quality regardless of throughput. On startup, begin at lowest quality and ramp up over 3-4 segments to minimize time-to-first-byte. Log all quality switches for analytics to tune thresholds.

Q2: How would you design the recommendation engine?

Answer: Use a multi-stage pipeline: (1) Candidate generation via collaborative filtering (matrix factorization on user-song interaction matrix) produces ~1000 candidates. (2) Ranking model (gradient-boosted trees or neural network) scores candidates using features: audio similarity, user context (time, device, recent listens), social signals (friends' activity). (3) Re-ranking for diversity (avoid too many songs from same artist/genre). (4) Serve via feature store with pre-computed embeddings; update user vectors in near-real-time as they listen. Handle cold start with content-based features and onboarding genre preferences.

Q3: How do you handle the cold-start problem for new users?

Answer: During onboarding, ask users to select 3-5 favorite artists/genres. Use these as seeds for content-based recommendations. Track implicit signals aggressively in first sessions (skips = negative, full listens = positive, repeats = strong positive). Blend popular/trending content with seed-based recommendations. Within 20-30 interactions, collaborative filtering becomes viable. For new songs, use audio feature analysis (tempo, energy, valence) to place them in the embedding space near similar existing songs.

Q4: How would you design the offline download system? (Hint-only)

Hints:

• Think about encryption at rest (per-device keys) and license validation intervals
• Consider storage management: quality tier selection for downloads, storage quota per subscription tier, background download scheduling on WiFi

Q5: How would you handle a viral song that suddenly gets 100x normal traffic? (Hint-only)

Hints:

• Think about CDN cache warming strategies and origin shielding
• Consider pre-emptive replication to edge nodes based on trending signals, and how your ABR strategy might temporarily favor lower bitrates to reduce bandwidth pressure

---

Counter Questions to Ask Interviewer

1. Scale: What's the expected user base? Are we designing for 10M or 500M users? This affects sharding strategy and CDN investment.
2. Geographic scope: Single region or global? This determines CDN topology and licensing complexity.
3. Content type: Music only, or also podcasts, audiobooks, live radio? Each has different streaming characteristics.
4. Monetization priority: Is the free tier a funnel to premium, or a standalone ad-revenue product? This affects ad infrastructure investment.
5. Latency requirements: Is this for on-demand only, or do we need live/real-time features (listening parties, live radio)?
6. Existing infrastructure: Are we building on a specific cloud provider? Do we have existing CDN contracts?
7. Offline requirements: Which markets require robust offline support (emerging markets with poor connectivity)?
8. Social features priority: Is social (friends, activity feed, collaborative playlists) a core differentiator or nice-to-have?

---

References

1. Spotify Engineering Blog - Architecture deep-dives on content delivery, recommendation systems, and audio quality: engineering.atspotify.com
2. HLS Specification (Apple) - RFC 8216: HTTP Live Streaming protocol specification; segment format, playlist structure, and adaptive bitrate rules
3. DASH Specification (MPEG) - ISO/IEC 23009-1: Dynamic Adaptive Streaming over HTTP; MPD format, segment addressing, and adaptation logic
4. Audio Codec Comparisons - Listening tests and technical analysis of AAC vs OGG Vorbis vs MP3 at various bitrates (hydrogenaudio.org)
5. ABR Algorithm Research - "A Buffer-Based Approach to Rate Adaptation" (Stanford, 2014); "Pensieve: Neural Adaptive Video Streaming" (MIT, 2017)
6. CDN Architecture for Streaming - Akamai and Cloudflare whitepapers on edge caching strategies for media delivery
7. Recommendation Systems - "Deep Neural Networks for YouTube Recommendations" (Google, 2016); matrix factorization techniques for implicit feedback datasets

Related Topics

• Strategy Pattern
• State Pattern
• Iterator Pattern
• Observer Pattern
• Decorator Pattern
• Building Resilient Systems