Design Spotify

Problem statement

Design an on-demand music streaming platform like Spotify. Users search a catalog of roughly 100 million tracks, start playback within two seconds on any device, jump between tracks gaplessly, build and share playlists, receive personalized mixes such as Discover Weekly, and keep music playable offline behind an encrypted local cache. The platform must serve hundreds of millions of daily listeners, negotiate licensing and royalty reporting with rights holders per region, and do all of it at a per-stream bandwidth cost low enough that a subscription margin survives.

The trap in this question is treating it as "Netflix for audio". It is not. Video systems amortize multi-megabyte segments over minutes of viewing; audio systems must deliver thousands of tiny, latency-critical byte ranges per user session, and the business model hinges on three things video does not have: per-second royalty accounting, regional rights that change what is playable mid-catalog, and a recommendation surface users treat as the product itself.

Spotify reported 626 million monthly active users and 246 million Premium subscribers in Q3 2024, and the catalog surpassed 100 million tracks. These are public company figures and anchor our sense of scale; every uncited number in this answer is an explicit design assumption.

The two planes

1. Control plane: catalog metadata, search, playlists, social graph, personalization, entitlements, play reporting. This plane is request/response, read-heavy, and can tolerate hundreds of milliseconds.
2. Byte plane: the actual audio bytes from storage to speaker. This plane is bandwidth-dominated, latency-critical for time-to-first-audio, and must survive flaky mobile networks.

A strong answer keeps these planes separate. The control plane decides WHAT you may hear; the byte plane decides HOW FAST it arrives. Mixing them — for example, routing audio through the same API gateway as metadata — is the most common candidate failure.

Why the problem is hard

• Time-to-first-audio under two seconds on mobile, including license lookup and range requests.
• Gapless transitions: the next track's first bytes must be warming before the current track ends.
• 60 million concurrent listeners at peak, each holding a long-lived stream, not a short HTTP request.
• Regional rights: a track playable in Sweden may be blocked in Japan; the cache must respect license expiry.
• Royalty precision: every stream must be attributable to a track, user, territory, and timestamp for payout.
• Personalization at weekly cadence for 600M+ users — batch ML over petabytes of listening events.

Public operating baseline versus design assumptions

Public evidence establishes the category is real and large. Spotify's investor relations report 626M MAU and 246M Premium subscribers (Q3 2024), and engineering blog posts describe the audio delivery stack, the recommendation system, and the data platform. Netflix, YouTube, and Apple publish figures for adjacent streaming workloads that inform CDN and encoding choices.

For capacity planning this answer explicitly assumes: 250M DAU, 60M concurrent listeners at global peak, 3B stream starts per day, and a 3× event peak for release days and evening hours. Unless a number is tied to a named company, it is a stated design assumption.

The five architectural layers

1. Client layer: playback engine, local encrypted cache, ABR selector, offline vault.
2. Edge layer: CDN for audio segments, WebSocket presence, TLS termination.
3. Control services: metadata, playlists, search, entitlement, social, notifications.
4. Intelligence layer: recommendation pipelines, ranking models, event ingestion.
5. Governance layer: rights catalog, royalty ledger, compliance, audit.