Spotify Audio Streaming System Design

Spotify is the world’s largest music and podcast streaming platform. As of its Q1 2026 earnings (reported 28 April 2026), it had ~761 M monthly active users (MAU) and ~293 M paid Premium subscribers (Spotify Newsroom, Q1 2026) — up from the ~600 M / ~240 M of 2024, a reminder that these figures grow every quarter and should always be read with an as-of date. It distributes a catalog on the order of ~100 M music tracks plus several million podcasts to clients across mobile, desktop, web, smart speakers, cars, and game consoles. Compared to video platforms (YouTube, Netflix), Spotify operates at a different bandwidth scale — a 320 kbps audio stream is roughly two orders of magnitude cheaper than a 1080p video stream — but at a substantially higher catalog-rate and recommendation-update tempo: with millions of new tracks per year and listening sessions averaging multiple skips per minute, the recommendation and discovery surface is the central engineering investment. Spotify is famous for three things in the literature: an early peer-to-peer (P2P) streaming hybrid (phased out starting April 2014, per TorrentFreak and TechCrunch), the Discover Weekly personalized playlist (launched 2015), and an event-delivery pipeline that ingests every play, skip, and click for analytics and recommendation training (originally Kafka + Hadoop on-prem, now Pub/Sub + Dataflow on Google Cloud). Note that the long-promised lossless tier — teased as “Spotify HiFi” in 2021 — finally shipped in September 2025 as Lossless (up to 24-bit/44.1 kHz FLAC, included free for Premium; see §1).

1. Functional and Non-Functional Requirements

Functional

• Stream music and podcasts by track ID, with adaptive bitrate (96 / 160 / 320 kbps for music; lower for podcasts). Gapless playback for albums.
• Search — free-text across artists, albums, tracks, podcasts, episodes, playlists, and users.
• Playlists — user-created (public, private, collaborative) and algorithmically-curated (Discover Weekly, Release Radar, Daily Mixes).
• Library and offline downloads — save tracks for offline use with DRM-encrypted local cache.
• Recommendations — Home page rows, autoplay queue, podcast suggestions, similar-artist recommendations.
• Social features — follow other users, share tracks, see what friends are listening to (in select markets), Spotify Wrapped (annual personalized recap).
• Audio analysis — every track is analyzed for tempo, key, energy, danceability, etc. (the Echo Nest API legacy), exposed via the Web API for third-party apps.
• Podcast hosting and distribution — Spotify hosts podcasts (via Spotify for Podcasters / formerly Anchor) and ingests RSS feeds for non-hosted shows.
• Ad insertion — for free-tier users, ads are stitched into the audio stream.
• Device control — Spotify Connect lets a phone control playback on a speaker / TV / car.

Non-Functional

• Subscriber base ~761 M MAU, ~293 M paid Premium (Q1 2026 figures, per Spotify Newsroom; growing each quarter).
• Time-to-first-byte ≤ 200 ms — Spotify’s published target for audio start latency, much tighter than video because users are conditioned to instantaneous music.
• Continuous-play interruption ≈ zero. Skipping a track must start the next within ~200 ms.
• Catalog freshness — a newly released track must be playable within minutes of label submission and discoverable in search within an hour.
• Availability ≥ 99.95% on the play path; the catalog-update path tolerates more downtime.
• Catalog scale ~100 M tracks (not 100 M files — many tracks have multiple bitrate variants and per-region licensing variants).
• Audio quality — lossy Ogg Vorbis (96 / 160 / 320 kbps on desktop and mobile) and AAC (128 / 256 kbps on the web player and Google Cast), per Spotify’s audio-formats support page. The lossless FLAC tier — first teased as “Spotify HiFi” in 2021, then quiet for years — launched on 10 September 2025 as Lossless, streaming up to 24-bit/44.1 kHz FLAC, included at no extra cost for Premium and rolling out to 50+ markets through October 2025 (Spotify Newsroom, 2025-09-10). Lossless requires Wi-Fi and a wired or Spotify Connect path; Bluetooth cannot carry it.
• Geographic reach — sub-200 ms first-byte from any populated country; offline support for users in transit or low-connectivity regions.

2. Capacity Estimation

Catalog storage. ~100 M tracks × ~3 bitrate variants × ~3 minutes average × ~32 KB/sec average (across bitrates) ≈ ~5 PB of master audio. With multiple codec re-encodings and regional variants, the global catalog footprint is on the order of low tens of PB — manageable for any tier-1 cloud provider.

Egress bandwidth. ~50 M concurrent peak listeners × ~200 kbps average effective bitrate = ~10 Tbps. A fraction of YouTube / Netflix scale, but still requires CDN distribution.

Event volume. Every play, skip, like, scroll, and ad-impression emits an event. Spotify’s “Brief History of Event Delivery” blog (2019) reports ingesting hundreds of billions of events per day. Kafka throughput on this is hundreds of GB / minute.

Search index. ~100 M tracks plus ~50 M artists / albums / playlists × ~kB-of-metadata = ~hundreds of GB of inverted-index data. See Inverted Index for the data structure.

Playlist storage. ~5 B user-created playlists × ~50 average tracks × ~16-byte track ID ≈ ~4 TB; trivial.

Recommendation features. Per-user listening history, per-track audio embeddings (~100-dim float vectors), per-artist embeddings — collectively hundreds of TB.

3. API Sketch

The viewer-facing API decomposes into:

# Auth & profile
POST   /api/token                                              → OAuth2 token
GET    /api/me                                                 → user profile

# Catalog
GET    /api/tracks/{trackId}                                   → metadata
GET    /api/albums/{albumId}                                   → album + track list
GET    /api/artists/{artistId}                                 → artist + popular tracks

# Search
GET    /api/search?q=...&type=track,artist,album,playlist      → ranked results

# Playback
GET    /api/playback/uri?trackId=...&format=ogg_vorbis_320     → signed segment URI
POST   /api/playback/event                                     → play / skip / pause event

# Playlists
GET    /api/playlists/{playlistId}
POST   /api/playlists                                          → create
POST   /api/playlists/{playlistId}/tracks                      → add tracks
GET    /api/me/playlists                                       → my playlists
GET    /api/recommendations?seed_tracks=...&seed_genres=...    → recommendations

# Library / following
PUT    /api/me/tracks/{trackId}                                → save to library
PUT    /api/me/following?type=artist&ids=...

# Spotify Connect
GET    /api/me/player/devices
PUT    /api/me/player/play?device_id=...

The interesting endpoint is /api/playback/uri: instead of returning bytes, it returns a signed, short-lived URL pointing to a CDN edge. The CDN authorizes the URL via the signature (HMAC of the parameters with a server-side secret), serves the encrypted audio chunks, and the client decrypts in-memory. This separates authorization (handled by Spotify backend) from delivery (handled by CDN), which is what makes audio delivery cheap.

4. Data Model

Spotify’s data layer mirrors the multi-store pattern common to large consumer services:

(A) Object store / CDN-backed audio storage. Audio chunks (typically Ogg Vorbis at 96 / 160 / 320 kbps and AAC for iOS / web) live in object storage (originally on-prem, now Google Cloud Storage post-cloud migration). Each chunk is ~10 seconds of audio for ABR-style streaming, encrypted at rest with per-track keys. The CDN serves these via signed URL.

(B) Cassandra clusters for high-write per-user data: listening history, library, played-recently, follow graph entries. Spotify has been one of Cassandra’s largest public deployments since the early 2010s and has contributed significantly to the project (the tombstone-behavior blog post 2018 is one of many). See Consistent Hashing and LSM Tree for Cassandra’s mechanics.

(C) PostgreSQL for canonical catalog metadata that is read-heavy and write-light (the canonical track / album / artist record), with strong consistency requirements for licensing and royalty reporting.

(D) Bigtable (post-cloud-migration) for very-high-write time-series workloads.

(E) Elasticsearch for search.

(F) Pub/Sub + Dataflow for the event pipeline, replacing on-prem Kafka + Hadoop after the 2016–2018 cloud migration documented across multiple Spotify blog posts.

(G) HDFS / BigQuery for analytics and ML training data lake.

A simplified shape:

tracks:        track_id (PK) | album_id | artist_id[] | title | duration_ms |
                isrc | popularity | audio_features (JSON)
albums:        album_id (PK) | artist_id[] | title | release_date | genre[]
artists:       artist_id (PK) | name | popularity | embedding (vector)
playlists:     playlist_id (PK) | owner_id | title | is_collab | track_ids[]
play_events:   (user_id, ts) PK | track_id | duration_ms | reason_started | reason_ended
                (Cassandra: partitioned by user_id, clustered by ts)
follows:       (user_id, followee_id) PK | type {artist|user} | followed_at
audio_features: track_id (PK) | tempo | key | energy | danceability |
                acousticness | instrumentalness | embedding (vector)

5. High-Level Architecture

flowchart TB
    Client[Spotify Client<br/>Mobile / Desktop / Web] -->|browse| EdgeAPI[Edge API<br/>Backend-for-Frontend]
    EdgeAPI --> CatalogSvc[Catalog Service]
    EdgeAPI --> SearchSvc[Search Service]
    EdgeAPI --> RecsSvc[Recommendations<br/>Service]
    EdgeAPI --> PlaylistSvc[Playlist Service]
    EdgeAPI --> SocialSvc[Social Graph<br/>Service]
    EdgeAPI --> AuthSvc[Auth / Token]

    CatalogSvc --> CatalogDB[(PostgreSQL<br/>Catalog)]
    SearchSvc --> ESIdx[(Elasticsearch<br/>Inverted Index)]
    PlaylistSvc --> PlaylistDB[(Cassandra<br/>Playlists)]
    SocialSvc --> SocialDB[(Cassandra<br/>Follow Graph)]
    RecsSvc --> RecsCache[(Bigtable + Cache)]
    RecsSvc --> ANNIdx[(Annoy / FAISS<br/>Vector Index)]

    Client -->|signed URI fetch| AudioCDN[(Audio CDN<br/>Edge POPs)]
    AudioCDN -.cache miss.-> Origin[(Origin Object<br/>Store - GCS)]

    Client -->|play / skip events| EventGW[Event Ingest<br/>Gateway]
    EventGW --> PubSub((Pub/Sub))
    PubSub --> Streaming[Streaming<br/>Dataflow]
    Streaming --> BigQuery[(BigQuery<br/>Analytics)]
    Streaming --> RecsTrain[Recs Training<br/>TPU/GPU]
    RecsTrain --> RecsCache
    RecsTrain --> ANNIdx

Walk-through. The diagram has three concurrent flows. The browse flow (top) is conventional: an edge API fans out to half a dozen domain microservices, each backed by its own data store. The play flow (middle) is the bandwidth-dominant path: client fetches signed URIs and pulls audio chunks from a CDN, with origin only seen on misses. The event flow (bottom) is what makes Spotify’s recommendations work — every play and skip becomes an event in Pub/Sub, processed in stream by Dataflow, written to BigQuery for analytics, and used to retrain the recommendation models that feed Annoy / FAISS vector indexes for online retrieval. The crucial architectural commitment is that every interaction is a training signal, processed at scale with low enough latency that today’s listening shapes tonight’s Discover Weekly.

6. Request Flow — Playing a Track

sequenceDiagram
    participant C as Client
    participant E as Edge API
    participant Cat as Catalog Svc
    participant DRM as DRM / Key Svc
    participant CDN as Audio CDN POP
    participant O as Origin Storage
    participant K as Pub/Sub

    C->>E: POST /play {trackId, deviceId}
    E->>Cat: getTrack(trackId, region)
    Cat-->>E: metadata + chunk URI pattern + bitrate options
    E->>DRM: requestKey(trackId, deviceId)
    DRM-->>E: ephemeral track key + signed chunk URLs
    E-->>C: chunk URLs + key (key encrypted to device)
    loop per chunk (~10 s of audio)
        C->>CDN: GET /chunk/{key} (signed URL)
        alt cache hit
            CDN-->>C: encrypted chunk bytes
        else cache miss
            CDN->>O: GET chunk
            O-->>CDN: bytes
            CDN-->>C: bytes
        end
        C->>C: decrypt + decode + queue audio
    end
    C->>E: POST /event {playStarted, trackId, ts}
    E->>K: publish event

The choreography highlights two design decisions. First, the edge API issues per-track DRM keys rather than long-lived keys — so a track can only be played by a specific device for a bounded time. Second, the CDN never sees decryption keys: it delivers ciphertext, the client decrypts. This means CDN compromise leaks ciphertext only, and revoking an ex-subscriber’s access requires only invalidating their key store on the next request.

7. Deep Dive — Three Critical Components

7.1 The (Now-Deprecated) Peer-to-Peer Streaming Layer

For its first ~5 years (Spotify launched October 2008; P2P phase-out began April 2014), the desktop client uniquely combined server-side streaming with peer-assisted delivery: each desktop client cached recently-played tracks and could serve those tracks to other clients over the Internet. The Kreitz & Niemelä 2010 IEEE P2P paper “Spotify — Large Scale, Low Latency, P2P Music-on-Demand Streaming” gives the authoritative byte breakdown: over the measurement period, 8.8% of music data came from Spotify’s servers, 35.8% from the peer-to-peer network, and 55.4% from the client’s own local cache. The headline result is that the combined cache + P2P contribution offloaded ~91% of music bytes away from Spotify’s servers — not, as is sometimes misremembered, a simple “35% peers / 65% servers” split. The same paper reports a median time-to-first-byte (start-of-playback latency) of 265 ms including cached tracks; with prefetching disabled the median rose to 390 ms, and the fraction of playbacks suffering a stutter was just 1.8% over the live measurement.

The protocol was carefully designed for music’s specific access pattern. Audio was encoded as Ogg Vorbis at quality q5 (variable bitrate, ~160 kbps) by default, with q9 (~320 kbps) for Premium; peers never re-encode, so a q9 peer cannot serve a q5 requester. To keep latency low, the latency-critical initial segment of a track is fetched from the server while the client simultaneously searches the P2P overlay for peers; peers are then throttled so they do not run more than ~15 seconds ahead of the playback point, and once enough buffer and peers are available the client streams predominantly from peers. Roughly 39% of playbacks were random-access (user clicks a specific track) versus 61% predictable sequence (album/playlist order), which is what makes prefetching the next track worthwhile. The local cache used an LRU eviction policy (see LRU Cache) with a default cap of ~10% of free disk, bounded between 50 MB and 10 GB.

The desktop P2P system was phased out starting in April 2014 — Spotify’s spokesperson Alison Bonny said they were “gradually phasing out the use of our desktop P2P technology” because “we’re now at a stage where we can power music delivery through our growing number of servers” (TorrentFreak; TechCrunch). The drivers:

1. Mobile and web clients (which never ran the P2P protocol — it was desktop-only) had become the dominant platforms.
2. Server / CDN bandwidth costs and Spotify’s own server footprint had grown to the point where P2P’s operational complexity was no longer worth it.
3. The growing catalog eroded caching efficiency (the long-tail problem — most users want different tracks, so a random peer is less likely to hold what you need).

It remains a textbook case of a clever optimization that was correct for its time and obsolete five years later — a useful reference for system design discussions about “should we add P2P / edge-compute / etc.”

7.2 The Recommendation Stack — Discover Weekly and Audio Embeddings

Spotify’s recommendation stack is the platform’s competitive moat. Discover Weekly (launched 2015), a personalized 30-track playlist refreshed every Monday, demonstrated that algorithmic recommendations at scale could displace human curation as the primary discovery surface. The Discover Weekly engineering blog (2015) describes the stack: collaborative filtering on listening history plus content-based audio analysis plus natural-language analysis of music blogs.

The three signals:

Collaborative filtering — the matrix factorization workhorse: an N-user-by-M-track binary play matrix (or weighted by play counts) is approximated as a low-rank product R ≈ U V^T, where each row of U is a user latent vector and each row of V is a track latent vector. Tracks similar in the latent space are recommended. (Original technique: see Matrix Factorization and Collaborative Filtering for full details.)

Audio content features — for new tracks with insufficient listening data (the “cold start” problem), a deep convolutional network is trained on raw audio (mel-spectrograms) to predict the latent vectors that collaborative filtering would have produced. The foundational van den Oord, Dieleman & Schrauwen NeurIPS 2013 paper “Deep content-based music recommendation” established this approach. The paper itself was authored at Ghent University (not at Spotify, as is sometimes claimed); co-author Sander Dieleman subsequently did a Spotify internship in 2014 and extended the technique against Spotify’s much larger catalog and collaborative-filtering latent vectors, which he documented in his blog post “Recommending music on Spotify with deep learning”. New track? Run the audio through the CNN, get a latent vector, recommend it to users whose history matches that vector.

Natural-language analysis — Spotify’s “cultural vector” pipeline scrapes music blogs and other text for adjectives associated with each artist and constructs an embedding from the text co-occurrences. Useful for genre / mood / vibe matching.

These three signal sources are blended via a learned ranker, then served from an approximate nearest neighbor (ANN) index. Historically this was Spotify’s own open-source Annoy library (random-projection trees, 2013). In October 2023 Spotify open-sourced its successor, Voyager, built on the Hierarchical Navigable Small World (HNSW) graph algorithm — reported as >10× faster than Annoy at equal recall and using up to 4× less memory; Voyager has served production traffic at Spotify since 2022. ANN at ~100 M tracks × ~100-dim embedding × tens of millions of queries per minute is the central serving constraint. Brute-force nearest-neighbor requires O(N) per query; tree-based ANN (Annoy) gives roughly O(log N) lookup, while graph-based ANN (HNSW/Voyager) gives sub-linear traversal with high recall — both trading a small recall loss for a large latency win, which is fine for recommendations.

Inside Annoy: random-projection trees. Annoy works by projecting the embedding space onto a random hyperplane at each tree node and recursively splitting points into left/right children based on which side of the hyperplane they fall on. The resulting tree has logarithmic depth, and a single tree’s leaf cluster contains a small set of nearest-candidate points. With multiple independent trees (a forest of 10–100), the union of the leaves a query falls into produces a high-recall candidate set; the candidates are then re-scored exactly. The cost is O(log N) per tree per query, plus the small union and re-rank step. The recall depends on tree count: more trees → more candidates → higher recall but higher latency. The tradeoff curves are documented on the Annoy README.

The Annoy index, once built, is memory-mapped — multiple processes can share the same index without each loading its own copy. This was a deliberate design choice for Spotify’s recommendation servers, where many service replicas read the same index. Memory-mapping also enables fast process restarts because the index doesn’t need to be re-loaded into memory after a deploy.

7.3 The Event Delivery Pipeline

Every meaningful action in a Spotify client emits an event: track started, track skipped, track completed, ad impression, social interaction. The 2019 Spotify engineering blog “A Brief History of Event Delivery” traces three generations:

1. Pre-2014: scribed-style file-based collection on bare metal, batch-loaded to Hadoop.
2. 2014–2018: Kafka → HDFS, with Hadoop / Hive batch processing. This was the on-prem era.
3. 2016–onward (cloud era): Pub/Sub → Dataflow → BigQuery.

The throughput cited in 2019: hundreds of billions of events per day, with hundreds-of-GB-per-minute peak ingest. The delivery guarantees are:

• At-least-once. The client retries on send failure; downstream deduplication is the consumer’s responsibility (typically by event ID).
• Bounded staleness. Event-to-warehouse target of minutes for batch and sub-second for streaming consumers.
• Schema enforcement. Every event type has a schema registered in a central registry; producers must serialize against that schema. This avoids the “what does field 7 mean” problem that plagues legacy event systems.

The reason this matters architecturally: training Discover Weekly requires recent user behavior, and recommendation freshness is a competitive lever. A pipeline that takes 24 hours to surface today’s listens into tomorrow’s recommendations is a worse product than one that takes 4 hours. Spotify’s investment in cloud-native streaming (Dataflow rather than legacy Hadoop batch) is justified specifically by the recommendation-loop latency.

Schema registry and event evolution. Each event type has a schema (Avro or Protobuf, depending on the era and team) registered in a central registry. Producers must serialize against the registered schema; consumers must deserialize against a compatible schema. Schema evolution (adding fields) is supported via Avro’s schema-resolution rules — old consumers can read new producers’ messages by ignoring unknown fields, and new consumers can read old producers’ messages by defaulting absent fields. Breaking changes (removing or renaming fields) require a deprecation cycle: dual-publish old + new schemas, migrate consumers, retire old schema. Without this discipline, an upstream change can silently break downstream training pipelines.

Sampling for cost control. Not all events warrant full storage. Engagement events that are useful for analytics (session duration, screen views) but not training are sampled in production — say, 1% of events flow through the full pipeline, with the rest summarized or discarded. Recommendation training events (plays, skips, completes) are kept at 100%.

8. Scaling Strategies

Squad / Tribe organizational model. Spotify’s “Spotify Engineering Culture” video (2014) and subsequent blog posts described the organizational structure of small autonomous “squads” grouped into “tribes” with cross-cutting “chapters” and “guilds.” This is not a technical architecture decision, but it’s tightly coupled to the microservice architecture: each squad owns a small number of services and ships independently, mirroring the Conway’s Law alignment that also underpins Netflix’s design. Note: subsequent commentary (Spotify employees, ex-employees) has questioned how literally the model was applied internally; treat as historical influence rather than current ground truth.

Cloud migration (2015–2018). Spotify migrated from on-prem datacenters to Google Cloud Platform over ~2.5 years, replacing Hadoop with BigQuery / Dataflow, Kafka with Pub/Sub, and on-prem object storage with GCS. The migration was documented heavily on the engineering blog and is one of the largest published cloud-migration case studies.

A/B testing infrastructure. Spotify runs hundreds of experiments concurrently (search ranking, recommendation algorithms, UI changes, ad load). The infrastructure supports per-user variant assignment, per-experiment metrics computation, and significance testing — see forward reference AB Testing Platform System Design.

Edge POP CDN. Audio chunks are served from a multi-CDN strategy. Spotify’s 2020 engineering post “How Spotify Aligned CDN Services for a Lightning Fast Streaming Experience” names Fastly, Akamai, and Verizon as its CDN providers and describes standardizing CDN configuration on Fastly’s edge platform for public-facing assets (audio, video, cover art, artist images), with steering based on real-time latency and error-rate measurements.

Search at catalog scale. Search is sharded by document space (catalog tracks, podcasts, playlists each have separate indexes) using Elasticsearch. Per-shard query routing is documented in Distributed Search System Design (forward reference). The challenge unique to music: searches are highly multilingual (Spanish artist, Korean track title, Hindi lyric), demanding language-aware tokenization and analyzer chains.

Annoy, Voyager, and the open-sourced ANN libraries. Spotify’s Annoy is a C++ library for approximate nearest neighbor (ANN) search using random projection trees. Each tree splits the embedding space along a random hyperplane; the forest of trees is queried in parallel and the top-k candidates from each tree are merged. The asymptotic cost is O(log N) per query for a forest of fixed depth, with a small constant. The library was open-sourced ~2013 and adopted broadly outside Spotify. Ten years on, Annoy no longer scaled to Spotify’s needs, and after years of internal hnswlib experimentation Spotify built and open-sourced Voyager (October 2023), an HNSW-based library with Python and Java bindings that is >10× faster and up to 4× more memory-efficient than Annoy, and has been in production since 2022.

Multi-region replication. Spotify operates across multiple GCP regions to serve users at low latency and to provide failover. Cassandra cross-region replication is asynchronous; Pub/Sub topics are regional with explicit cross-region forwarders. The recommendation feature store is replicated everywhere because recs are read globally.

9. Real-World Deployment Notes and Citations

• P2P streaming. Kreitz & Niemelä 2010 IEEE P2P paper (8.8% server / 35.8% P2P / 55.4% cache; 265 ms median latency); Goldmann & Kreitz 2011. Phase-out began April 2014.
• Discover Weekly architecture. Spotify Engineering Blog 2015 and follow-ups.
• Audio embeddings via deep learning. van den Oord, Dieleman & Schrauwen, NeurIPS 2013 — authored at Ghent University; extended at Spotify during Dieleman’s 2014 internship (sander.ai blog).
• Event delivery generations. Brief History of Event Delivery, 2019.
• Annoy. github.com/spotify/annoy — the open-sourced ANN library.
• Cassandra contributions. Spotify engineering blog has multiple posts on Cassandra production lessons.

Most figures in this note are now cited inline to Spotify’s own materials. A few claims remain soft and are flagged below.

Uncertain

Verify: the catalog size (~100 M tracks) and exact current infrastructure spend — Spotify does not publish a precise live catalog count or per-vendor spend, so these are approximate/dated. The CDN vendor set (Fastly / Akamai / Verizon) is confirmed by Spotify’s 2020 blog but the vendor mix may have shifted since. The Squad / Tribe model is an organizational idealization from Spotify’s 2014 culture videos; multiple ex-employees have publicly said it was never applied as literally as the model suggests, so treat it as historical influence, not current ground truth. To resolve: cross-check the latest Spotify investor deck for catalog figures and a recent engineering post for the current CDN mix. uncertain

10. Tradeoffs

Dimension	Spotify’s Choice	Alternative	Why Spotify’s Choice
Audio bitrate ladder	96 / 160 / 320 kbps lossy	Lossless-only (FLAC)	Bandwidth cost; mobile data caps; lossy is psychoacoustically near-transparent at 320 kbps
Codec	Ogg Vorbis (desktop/mobile 96/160/320), AAC (web/Cast 128/256), FLAC (lossless since 2025)	MP3	Better compression efficiency at low bitrates; FLAC for lossless
CDN	Multi-vendor + own routing	Single CDN	Avoid vendor lock-in; route by real-time performance
P2P streaming	Built it (2008), removed it (2014)	CDN-only from start	P2P was right for cost in 2008; cloud bandwidth made it obsolete
Catalog DB	PostgreSQL (catalog) + Cassandra (per-user)	Single DB	Different write / consistency profiles
Recommendations	Multi-signal blend	Single-algorithm	No single signal handles cold start + popularity + freshness simultaneously
Search	Elasticsearch	Custom inverted index	Operational simplicity; multilingual support out of box
Event pipeline	Pub/Sub + Dataflow (post-cloud)	On-prem Kafka	Cloud-native ops + native BigQuery integration
ANN library	Annoy (open-sourced)	Brute-force	Latency budget for recommendations
Org model	Squad / Tribe (idealized)	Functional teams	Service ownership scales with team count

11. Pitfalls and Gotchas

1. Recommendation cold start. A newly added artist with zero plays gets no collaborative-filtering signal. Spotify mitigates with audio-CNN embeddings (van den Oord 2013), but those are imperfect — culturally novel music is harder to embed correctly.
2. Licensing complexity. Each track has region-specific availability (some countries have rights, others don’t), expiration dates, royalty calculation rules, and exclusivity windows. The catalog service must enforce all of this atomically on every play; a single missed check has financial and legal consequences.
3. Hot artist on launch day. A Taylor Swift release floods both the catalog (search QPS spikes) and the streaming layer (CDN cache fills). Pre-positioning audio chunks at edge is essential; warm-up scripts run 24 hours before scheduled releases.
4. Skip-rate bias in collaborative filtering. A user who plays a track for 10 seconds and skips probably disliked the track, but a naive play-count signal treats it as a positive. Spotify’s training data weights signals by completion fraction, not raw play count.
5. Podcast discovery. Podcasts have orders-of-magnitude longer durations than music tracks (hours vs minutes). The same recommendation primitives don’t transfer: a “next track” recommendation can fire every 3 minutes; a “next podcast episode” recommendation fires once per session at most. The recommendation model must treat them as separate domains.
6. Cassandra tombstone behavior. Spotify’s tombstone blog (2018) documents a long-running production headache: deletes in Cassandra create tombstones that compaction must eventually reap, but high-delete workloads create tombstone storms that crash queries. Mitigation: TTL-based deletion and compaction tuning.
7. Offline-mode license expiration. Subscribers downloading tracks for offline use receive DRM keys with bounded expiration (typically 30 days). If the user goes offline for longer, downloaded tracks become unplayable until a network ping re-licenses them. Edge cases: airline travel, prison sentences.
8. Spotify Connect race conditions. Phone hands off playback to a speaker; speaker hands off to TV; TV hands back to phone. The “now playing” state must remain consistent across devices in the presence of network partitions, which is genuinely hard — this is a small distributed-state-machine problem inside the platform.
9. Cross-tenant playlist abuse. Collaborative playlists can be edited by anyone with the URL, which has been used for abuse and spam. Rate limiting and abuse detection on playlist edits are necessary; see Token Bucket.
10. Royalty calculation precision. Each play generates a royalty payable to the rights holder (typically a fraction of a cent per play, computed via a complex per-rights-holder formula). At scale, rounding errors and double-counting can accumulate to material amounts. The play-event log must be audit-grade — every play must be uniquely accounted for, with replay-safe deduplication.
11. Catalog metadata reconciliation. Tracks arrive from multiple distributor pipelines (record labels, aggregators like Distrokid). The same track can have multiple ISRCs (International Standard Recording Codes) due to label re-issues, region-specific variants, and remastering. Deduplicating these into a canonical track ID is an ongoing data-quality battle.
12. Audio analysis re-runs. Audio features (tempo, key, energy, embeddings) are computed once per track, but the analysis algorithm itself improves over time. Re-running analysis over the full ~100 M-track catalog is a substantial batch job; managing the version skew between newly-analyzed tracks and old cached features is a quiet ongoing concern.
13. Playlist-cache thrashing. A user opening Discover Weekly triggers a cascade of cache fills — track metadata, artist metadata, album art, audio chunks for the first track. If any one of these subsystems is slow, the perceived load time for the playlist suffers. The edge API typically pre-warms by fetching all 30 tracks’ metadata in a single batch request rather than serially.
14. The “skip the first 5 seconds” listening pattern. Many users skip into songs after the intro. The audio CDN sees disproportionate traffic for the middle of tracks, not the start; cache-warming logic can’t naively pre-fetch from byte 0.

12. Common Interview Variants

• Design Spotify — the canonical music-streaming prompt.
• Design Apple Music / YouTube Music / Tidal — same primitives; differentiation is in catalog (Apple’s lossless catalog) and integration (YouTube’s shared catalog with video).
• Design SoundCloud — UGC ingest variant; closer to YouTube’s upload pipeline than to Spotify’s curated catalog.
• Design Audible / podcast platform — long-form, no need for sub-second latency; download-then-play dominates.
• Design a music recommendation engine — see Recommendation Engine System Design; Discover Weekly is a flagship case.
• Design an audio CDN — see Content Delivery Network System Design; audio is a simpler workload than video but the principles are the same.

13. Open Questions and Areas of Uncertainty

• Has Spotify HiFi (lossless) launched broadly? Resolved. It launched 10 September 2025 as Lossless — up to 24-bit/44.1 kHz FLAC, free for Premium, rolling to 50+ markets through October 2025 (Spotify Newsroom).
• What is the current ANN-library choice? Resolved. Spotify migrated from Annoy to the HNSW-based Voyager (open-sourced Oct 2023, in production since 2022) (Spotify Engineering).
• How does Spotify reconcile podcast hosting (where Spotify is the origin) with podcast distribution (where most podcasts are RSS-fetched from third-party origins)?
• What is the current ratio of P2P-style optimizations to pure CDN delivery? The 2014 retirement of desktop P2P doesn’t preclude later edge-compute or peer optimizations.
• How does the recommendation system handle the recent surge of AI-generated music in the catalog? Detection, attribution, and royalty allocation are open issues across the industry.

Uncertain

Verify: Spotify’s current AI-generated-music policy (detection, attribution, royalty allocation) and the podcast hosting-vs-RSS reconciliation are not documented in primary sources at the depth needed here. Reason: fast-moving policy area with no authoritative Spotify engineering write-up located during this pass. To resolve: check Spotify’s most recent newsroom/policy posts on AI music and any engineering post on podcast ingestion. uncertain

14. See Also

• Major System Designs MOC
• SWE Interview Preparation MOC
• YouTube Video Streaming System Design — sibling streaming platform (video)
• Netflix Streaming System Design — sibling subscription streaming
• Twitch Live Streaming System Design — live-first counterpart
• Content Delivery Network System Design — Spotify uses multi-CDN
• Consistent Hashing — Cassandra and CDN routing
• LSM Tree — Cassandra storage engine
• LRU Cache — per-node CDN cache eviction
• Inverted Index — search over catalog
• Recommendation Engine System Design — Discover Weekly architecture
• Matrix Factorization — collaborative filtering math
• Collaborative Filtering — algorithmic family
• Token Bucket — playlist edit rate limiting
• AB Testing Platform System Design — Spotify’s experimentation infrastructure
• Distributed Search System Design — Elasticsearch sharding