Spotify

Key Concepts

Sampling Rate determines how many times per second we measure the analog signal. CD-quality audio uses 44,100 Hz (44.1 kHz)—meaning 44,100 snapshots of air pressure every single second. Why 44.1 kHz? The Nyquist-Shannon sampling theorem states that to faithfully reproduce a signal, you must sample at at least twice the highest frequency you want to capture. Human hearing tops out around 20 kHz, so 2 × 20,000 = 40,000 Hz minimum. The extra 4,100 Hz provides headroom for the anti-aliasing filter.

Bit Depth defines the precision of each sample. At 16-bit depth, each sample can be one of 2¹⁶ = 65,536 possible amplitude values, yielding a theoretical dynamic range of ~96 dB. 24-bit depth (used in studio recording) provides 16,777,216 levels and ~144 dB dynamic range—far exceeding the capabilities of any playback hardware.

PCM (Pulse Code Modulation) is the raw, uncompressed digital audio format. A stereo 44.1 kHz / 16-bit PCM stream requires: 44,100 × 16 × 2 = 1,411,200 bits/second (~1.4 Mbps, or about 10 MB per minute). This is why compression is essential for streaming.

Psychoacoustic Masking

The psychoacoustic model is the secret weapon of lossy codecs. It exploits two phenomena:

Simultaneous masking: A loud sound at one frequency makes nearby quieter sounds inaudible. If a 1 kHz tone is playing at 80 dB, a 1.1 kHz tone at 40 dB is completely masked — the codec doesn't need to encode it.

Temporal masking: A loud sound makes quieter sounds inaudible for a short time before (pre-masking, ~5ms) and after (post-masking, ~100ms) it occurs. The codec can reduce precision during these masked windows.

By dividing audio into frequency bands and applying masking thresholds, codecs allocate more bits to perceptually important frequencies and fewer (or zero) bits to masked regions. This is why 320 kbps Ogg Vorbis can sound nearly identical to 1,411 kbps PCM—it's only encoding the ~23% of data your ears actually process.

What Spotify Actually Uses

Spotify encodes all music in Ogg Vorbis at multiple quality tiers, selected based on your subscription and settings:

The choice of Ogg Vorbis over MP3 or AAC comes down to licensing: Ogg Vorbis is completely royalty-free and open-source. At 320 kbps, double-blind ABX tests consistently show it is transparent (indistinguishable from the original) for the vast majority of listeners and audio material.

HTTP-Based Chunked Delivery

Spotify uses a proprietary protocol built on top of HTTP. Each track is divided into small chunks (typically a few seconds each). The client requests chunks via standard HTTP range requests from Spotify's CDN edge servers. This approach works through firewalls and proxies (unlike the UDP-based P2P protocol they used in early years).

The client maintains a playback buffer—typically 3–10 seconds of decoded audio ahead of the current playback position. If the buffer drops below a threshold, the client may switch to a lower bitrate. If bandwidth is abundant, it buffers further ahead. This adaptive bitrate strategy prevents interruptions on variable connections.

How Audio Streaming Differs from Video

Video protocols like HLS and DASH are built around manifest files (e.g., m3u8) listing segment URLs at various quality levels. The player downloads the manifest, then requests segments. Audio streaming at Spotify skips this complexity: the access point server tells the client the track's storage key and available bitrates directly. The client fetches chunks from the CDN using that key. Switching quality is seamless because all chunks are independently decodable Ogg pages. There is no need for I-frames or GOP structures like in video.

Microservices at Scale

Today Spotify runs 4,000+ microservices developed by autonomous "squads" (their take on agile teams). The tech stack is polyglot:

• Java — the backbone, running most backend services
• Python — data pipelines, ML training, internal tooling
• Go — performance-critical infrastructure services
• C / C++ — native client codecs, audio processing
• TypeScript / React — web player, internal dashboards

In 2018, Spotify migrated from self-managed datacenters to Google Cloud Platform (GCP), one of the largest cloud migrations in history. They now use GKE (Google Kubernetes Engine) for container orchestration, BigQuery for analytics, Cloud Pub/Sub for messaging, and Cloud Storage for audio files.

CDN Architecture

Spotify operates a hybrid CDN strategy: they use Google Cloud CDN combined with partnerships with third-party CDN providers (historically including Fastly and Akamai) plus their own edge caching infrastructure in key markets. Audio files are stored in Google Cloud Storage as the origin, with multiple cache tiers:

Popular tracks are cached at edge Points of Presence (PoPs) close to users. Long-tail tracks may require fetching from regional caches or even the origin. The cache hit ratio for popular tracks exceeds 95%—music consumption follows a power law where a small percentage of tracks account for the majority of plays.

Historical: Peer-to-Peer (P2P)

In its early years (2008–2014), Spotify used a P2P network to reduce server costs. The desktop client would cache recently played tracks and serve them to nearby users, similar to BitTorrent. At peak, P2P accounted for up to 40% of all audio delivery. However, P2P caused issues: it consumed users' upload bandwidth, raised ISP concerns, and was complex to manage. As CDN costs dropped and mobile (which can't easily do P2P) became the dominant platform, Spotify phased out P2P entirely by 2014.

Service Communication

With 4,000+ services, how they talk to each other matters enormously:

• gRPC — the primary synchronous RPC framework, using Protocol Buffers for serialization. Low-latency, strongly typed, with built-in load balancing.
• Hermes — Spotify's internal pub/sub messaging system for asynchronous, event-driven communication. When a user saves a track, an event is published that dozens of downstream services consume (recommendation updates, analytics, social feed, etc.).
• Google Cloud Pub/Sub — used for large-scale data pipeline events (play events, log aggregation).
• Service discovery is handled through DNS-based discovery on Kubernetes, with custom service mesh components for routing, retries, and circuit breaking.

Data Storage

What Happens When You Press Play

1. UI event fires — the play button tap is captured by the platform UI layer, which calls into the core client library.
2. Resolve track — the client looks up the track's Spotify URI (e.g., spotify:track:6rqhFgbbKwnb9MLmUQDhG6) in the local metadata cache. If not cached, it requests metadata from the Catalog Service.
3. Request playback token — the client contacts the Access Point (AP) server to get a playback token. The AP verifies the user's subscription, checks geo-restrictions, and returns a CDN file key + access token.
4. Fetch audio chunks — using the CDN key, the client makes HTTP range requests to the nearest CDN edge server. The first chunk is prioritized for fast start-up (typically <200ms to first audio).
5. Decrypt & decode — audio chunks are decrypted (Spotify uses AES-128 encryption on stored files), then decoded from Ogg Vorbis to raw PCM samples.
6. Apply audio processing — volume normalization, equalizer settings, and crossfade mixing are applied to the PCM buffer.
7. Output to audio device — PCM samples are written to the platform's audio output API (CoreAudio on Apple, AAudio/OpenSL ES on Android, WASAPI on Windows).
8. Report playback event — the client sends a play event to Spotify's event pipeline (track ID, timestamp, duration, skip/complete, device type). This feeds recommendations, royalty calculations, and analytics.

Spotify Connect

Spotify Connect is the protocol that lets you control playback on one device from another—start a song on your phone, then seamlessly transfer it to your smart speaker or desktop. The architecture is elegant:

Every Spotify client maintains a persistent connection to the Access Point server. Each device registers itself as a "connect endpoint." When you transfer playback, no audio is actually streamed between devices. Instead, the controlling device sends a command message through the AP to the target device: "Play this track, at this position, in this context." The target device then independently fetches the audio from the CDN. This means Spotify Connect works even on devices with no Bluetooth or local network connection to each other—they just need internet access.

Matrix Factorization

At Spotify's scale, both pure user-user and item-item approaches are impractical. Instead, they use matrix factorization—specifically, implicit feedback ALS (Alternating Least Squares). The approach:

Imagine a gigantic matrix with 600M rows (users) and 100M columns (tracks). Each cell represents how much a user has interacted with a track (play count, save, skip, playlist add). This matrix is extremely sparse (>99.99% empty). Matrix factorization decomposes it into two smaller matrices: a user matrix (600M × k) and a track matrix (100M × k), where k is typically 40–200 latent factors.

Each user and each track is now represented as a vector in k-dimensional space. The dot product of a user vector and a track vector predicts how much that user will like that track. To generate recommendations, you find tracks whose vectors are closest to the user's vector. Training this model on billions of interactions requires distributed computing (they use custom implementations on Google Cloud Dataflow and TensorFlow).

Implicit Feedback Signals

Unlike Netflix (where users rate movies 1–5 stars), Spotify primarily relies on implicit signals:

Genre Classification

Spotify maintains an internal genre taxonomy with over 6,000 micro-genres (you can explore them at everynoise.com, created by Spotify's Glenn McDonald). Genres are assigned using a combination of cultural NLP data, audio features, and crowd-sourced tagging. Each artist can belong to multiple genres, and each genre is defined by its centroid in audio-feature space plus its cultural descriptors. This granular taxonomy enables extremely precise recommendations—the system knows the difference between "vaporwave" and "future funk" or "midwest emo" and "math rock."

The Discover Weekly Pipeline

1. Build taste profile: Analyze the user's listening history from the past several weeks. Identify their preferred genres, artists, audio features, and listening patterns (what they play repeatedly vs. skip).
2. Collaborative filtering: Find the user's "taste neighbors"—other users with overlapping taste profiles. Collect tracks that taste neighbors love but the target user hasn't heard.
3. NLP cultural filtering: Filter and rank candidates using text-based cultural vectors. This ensures the recommendations feel culturally coherent (not just acoustically similar).
4. Audio analysis scoring: Score remaining candidates against the user's preferred audio feature ranges. If a user primarily listens to high-energy tracks (0.8+), low-energy candidates are deprioritized.
5. Novelty & diversity: Apply the exploration vs. exploitation tradeoff. Some slots are "safe" recommendations (high confidence the user will like them); others are deliberate "stretch" picks to broaden taste. The system also ensures genre diversity—no playlist of 30 tracks from one genre.
6. Filtering: Remove tracks the user has already listened to, saved, or added to playlists. Remove explicit content if the user has a content filter enabled.
7. Assemble & deliver: The final 30 tracks are compiled into a playlist object and published every Monday at approximately midnight in each time zone.

Why Mondays?

Spotify's data shows that Monday is when users are most open to new music. After a weekend of playing familiar favorites at social events, Monday (especially Monday mornings) represents a return to individual listening—commutes, desk work, headphones. The team also considered that "music discovery" aligns with the psychological fresh-start effect of a new week.

Convolutional Neural Networks on Audio

Spotify pioneered the use of deep convolutional neural networks (CNNs) applied to mel-spectrograms—visual representations of audio where the x-axis is time, y-axis is frequency (on the mel scale, which approximates human perception), and color/intensity represents amplitude.

A mel-spectrogram effectively turns audio into an image, and CNNs are exceptionally good at image recognition. Spotify's models process 3–5 second spectrogram slices and learn to extract features like genre, mood, instrumentation, and vocal characteristics without any human labeling. The learned representations (embeddings) are used as content vectors in the recommendation pipeline.

Architecture

At the core is an inverted index—a data structure that maps every word (and n-gram) to the set of entities (tracks, artists, albums, playlists, podcasts) that contain it. The index is built from multiple metadata sources: track titles, artist names, album names, lyrics, genre tags, and more.

Search Ranking

Results are ranked by a learned model that considers:

• Text relevance — how well the query matches the entity name (BM25 + neural re-ranking)
• Popularity — global and regional play counts (a track with 1B streams ranks higher than one with 1K)
• Personalization — your listening history, saved artists, and playlist contents boost relevant results
• Recency — newly released tracks get a temporary boost
• Entity type — if you search an artist name, the artist result appears first, followed by their top songs and albums

The ranking model is a Learning to Rank (LTR) system trained on click-through data: given a query and the result the user actually selected, the model learns to surface similar results for similar queries.

How Getting on a Major Playlist Works

Artists and labels can submit unreleased tracks to Spotify's editorial team via Spotify for Artists at least 7 days before release. The submission includes genre tags, mood descriptions, and promotional context. The algorithmic system also surfaces trending tracks to editors. About 30% of editorial playlist additions come from algorithmic triggers (rapid increase in saves, Shazam identifies, social buzz). The remaining 70% are direct editorial picks based on listening, submissions, and cultural context.

Revenue Flow

The Per-Stream Rate

The commonly cited "$0.003–0.005 per stream" is an average, not a fixed rate. The actual payment per stream varies based on: the country where the listener is located (a stream from the US pays more than from India due to subscription pricing), whether the listener is on Free or Premium tier, and the total number of streams in that period. This rate has been relatively stable but is a source of ongoing tension between Spotify and artists/labels.

The Royalty Chain

When Spotify pays "rights holders," the money typically flows through multiple intermediaries before reaching the artist:

Additionally, publishing royalties (for songwriters) flow separately: Spotify pays publishing rights organizations (e.g., ASCAP, BMI, PRS), which pay publishers, who pay songwriters. An artist who both performs and writes might receive two separate (small) payments for each stream. Independent artists using distributors like DistroKid, TuneCore, or CD Baby typically keep 80–100% of the distributor's share, making per-stream economics significantly better for them.

Ad Delivery Architecture

Audio ads must be seamlessly inserted into the listening experience without buffering gaps or abrupt volume changes. Here's how it works:

1. Pre-fetch ad content: The client receives ad decisions from the ad server before the ad break. While the user is still listening to music, the ad audio file is downloaded and cached locally. This prevents any loading delay when the ad break begins.
2. Volume normalization: Ads are loudness-normalized to match the preceding music (targeting -14 LUFS, the same standard applied to music). This prevents the jarring experience of ads being louder than the music.
3. Seamless insertion: The player transitions to the pre-cached ad with a brief crossfade, plays the ad, then crossfades back to the next music track. The entire transition is handled locally by the client.
4. Impression reporting: The client reports ad impressions, completions, and interactions back to the ad server for billing and analytics.

Streaming Ad Insertion (SAI) for Podcasts

Podcast ads use a fundamentally different mechanism called Streaming Ad Insertion (SAI). Unlike traditional podcast ads (baked into the audio file by the creator), SAI dynamically stitches ads into the podcast stream at the time of playback. This enables:

• Targeting: Different listeners hear different ads based on demographics, interests, and location
• Impression tracking: Spotify can confirm the ad was actually heard (not just downloaded)
• Freshness: Old episodes can serve current ads instead of outdated ones
• A/B testing: Advertisers can test different ad creatives against different audiences

SAI works by the podcast containing timestamp markers where ads can be inserted. At playback time, the server assembles a personalized version of the episode with targeted ads stitched in at those markers. The stitching happens server-side, and the client receives what appears to be a single continuous audio stream.

Handling Traffic Spikes

When a major artist (Taylor Swift, Drake, Bad Bunny) drops a new album, Spotify experiences massive, sudden traffic spikes. The infrastructure must handle these gracefully:

• Pre-provisioning: For known release dates (announced weeks in advance), the infrastructure team pre-scales services—additional Kubernetes pods, CDN cache warming for the new tracks, and extra capacity on access point servers.
• Auto-scaling: GKE auto-scaling responds to real-time metrics (CPU utilization, request latency, queue depth). New pods can spin up in under 60 seconds.
• Circuit breakers: If a downstream service becomes overwhelmed, circuit breakers prevent cascade failures. The playback service, for instance, can gracefully degrade by serving slightly stale metadata rather than failing entirely.
• Load shedding: In extreme scenarios, non-critical features (social feed, canvas videos, animated covers) are deprioritized to protect core playback functionality.

Real-Time vs. Batch Processing

A/B Testing Infrastructure

At Spotify, every feature is an experiment. The A/B testing platform, built internally, supports thousands of concurrent experiments across all clients. Every user is randomly assigned to experiment buckets, and every interaction is tagged with the active experiments. This allows the data team to measure the causal impact of any change—from a new recommendation algorithm to a button color change—on metrics like stream count, session length, retention, and conversion.

The system handles the statistical complexity of running thousands of overlapping experiments (multiple testing correction, interaction effects between experiments, novelty effects) using sophisticated Bayesian methods. Results are surfaced in an internal dashboard where product teams can monitor experiment health and make ship/no-ship decisions with statistical rigor.

Event Schema: What a Single Play Event Contains

When you listen to a song for more than 30 seconds, the following (simplified) event is generated:

This single event feeds: royalty calculation, recommendation model training, A/B test analysis, artist analytics (Spotify for Artists), chart calculations, and capacity planning. Multiply by billions per day, and you understand why Spotify is fundamentally a data company that happens to stream music.