System Design: Spotify Architecture Deep Dive

Spotify serves over 600 million users across 180+ markets, streaming from a catalog of over 100 million songs and 6 million podcasts. Users collectively stream over 600 million hours of audio per day. Unlike video streaming where buffering for a few seconds is tolerable, music playback must start almost instantly and play without interruption — a gap of even half a second between songs breaks the experience.

The system behind this combines low-latency audio delivery, one of the most sophisticated recommendation engines in tech, and an organizational model that became a template for the entire industry.

Audio Streaming Architecture

Spotify’s core job is getting audio from its storage to your ears with minimal latency. This sounds simple, but the requirements are demanding: playback must start within 200 milliseconds of pressing play, there can be no audible gaps between songs, and the system must work on unreliable mobile networks.

Codec Selection and Audio Quality

Spotify uses Ogg Vorbis for free-tier streaming and AAC for premium. The quality tiers are:

Spotify Audio Quality Tiers:

Free Tier:
  Low:      24 kbps  (Ogg Vorbis) — extreme compression
  Normal:   96 kbps  (Ogg Vorbis) — acceptable on phone speakers
  High:    160 kbps  (Ogg Vorbis) — good for most listeners

Premium Tier:
  Very High: 320 kbps (Ogg Vorbis / AAC) — near-CD quality
  Lossless:  ~1411 kbps (FLAC) — CD quality, HiFi tier

Storage per song (average 3.5 minutes):
  96 kbps:   ~2.5 MB
  160 kbps:  ~4.2 MB
  320 kbps:  ~8.4 MB
  FLAC:      ~37 MB

Total catalog at 320 kbps: ~100M songs * 8.4 MB = ~840 PB
(Not all songs stored at all quality levels)

Streaming Protocol

Unlike video platforms that use HTTP-based adaptive streaming (DASH/HLS), Spotify’s original architecture used a custom peer-to-peer protocol combined with server-based delivery. They have since moved away from P2P toward a fully server-based model, but the streaming logic remains custom.

Audio Playback Flow:

1. User hits Play
   -> Client sends play request to Access Point (AP)
   -> AP authenticates, checks license, returns file location

2. Client begins streaming from CDN edge
   -> First 15 seconds downloaded immediately (burst mode)
   -> Remaining content streamed at 1.2-1.5x playback speed
   -> Excess bandwidth used to build ahead buffer

3. Buffer Management:
   -> Target: 30 seconds of audio buffered ahead
   -> If buffer drops below 10 seconds: increase download rate
   -> If buffer is full: pause downloading
   -> Network change (WiFi -> cellular): continue from buffer

4. Gapless Playback:
   -> While song A is playing, pre-fetch first segments of song B
   -> Crossfade handled client-side
   -> From user perspective: seamless transition

5. Quality Adaptation:
   -> Start with lower quality for instant playback
   -> If bandwidth is good, switch to higher quality
   -> Unlike video, switching audio quality mid-song is noticeable
      so Spotify prefers to start at the right quality

Access Points

Spotify’s Access Points (APs) are the entry servers that handle all client connections. Every Spotify client maintains a persistent TCP connection to the nearest AP. The AP handles authentication, service discovery, and routes requests to backend services.

Access Point Architecture:

  Spotify Client (phone/desktop/web)
      |
      | Persistent TCP connection
      v
  Access Point (AP)
      |-- Authentication (verify session token)
      |-- Connection management
      |-- Request routing to backend services
      |-- Push notifications (new playlist, friend activity)
      |
      +---> Audio Storage Service (fetch audio files)
      +---> User Service (profile, preferences)
      +---> Playlist Service
      +---> Social Service (friend activity)
      +---> Search Service

The AP layer is geographically distributed. When you open Spotify, your client connects to the nearest AP via DNS-based routing. If that AP fails, the client automatically reconnects to the next-nearest one.

Discover Weekly: ML at Scale

Discover Weekly is Spotify’s flagship recommendation feature — a personalized playlist of 30 songs, updated every Monday, for each of its 600M+ users. It has been called one of the most successful ML products ever launched, with users saving over 10 billion tracks from it in its first several years.

The Three Models

Discover Weekly combines three different recommendation approaches:

Discover Weekly Pipeline:

Model 1: Collaborative Filtering
  "Users similar to you also listened to..."
  
  Matrix factorization on the user-song interaction matrix:
  - Rows: 600M+ users
  - Columns: 100M+ songs
  - Values: play counts / implicit ratings
  - Output: user vectors and song vectors in latent space
  - Similar users = close vectors
  
  This catches patterns like: people who listen to
  Radiohead and Tame Impala also listen to King Gizzard.

Model 2: Natural Language Processing (NLP)
  Crawl the web for blog posts, reviews, and articles about music.
  Build word2vec-style embeddings for artists and songs
  based on how they are described.
  
  This catches cultural associations:
  "dreamy shoegaze" -> groups together bands described
  with similar language, even if their listeners do not overlap.

Model 3: Audio Analysis (CNN)
  Raw audio -> Convolutional Neural Network
  -> Audio feature embedding
  
  Analyzes: tempo, key, mode, energy, acousticness,
  danceability, time signature, spectral features.
  
  This catches sonic similarity: songs that SOUND alike
  even if they have different audiences and are described
  differently. Critical for recommending new/obscure songs
  with no listening data or web presence.

The Pipeline

Every Monday morning, Spotify runs the Discover Weekly pipeline for all 600M+ users. This is one of the largest batch ML jobs in the industry.

# Simplified Discover Weekly generation
def generate_discover_weekly(user_id):
    # Step 1: Get candidates from each model
    cf_candidates = collaborative_filter(user_id, n=200)
    nlp_candidates = nlp_similarity(user_id, n=200)
    audio_candidates = audio_similarity(user_id, n=200)

    # Step 2: Merge and deduplicate
    all_candidates = merge_candidates(
        cf_candidates, nlp_candidates, audio_candidates,
        weights=[0.5, 0.25, 0.25]
    )

    # Step 3: Filter out songs the user has already heard
    unheard = filter_listened(user_id, all_candidates)

    # Step 4: Rank by predicted engagement
    ranked = ranking_model.predict(user_id, unheard)

    # Step 5: Ensure diversity
    # Don't put 5 songs from the same artist in a row
    diverse_playlist = diversify(ranked, max_per_artist=2)

    # Step 6: Select top 30
    return diverse_playlist[:30]

The pipeline runs on Google Cloud Dataproc (managed Spark/Hadoop). Training the collaborative filtering model alone processes hundreds of terabytes of listening data.

Audio Feature Extraction

Spotify’s audio analysis system processes every song in the catalog through a CNN that extracts features like tempo, key, energy, and danceability. These features power not just recommendations but also features like the “Audio Features” cards in the Spotify for Artists dashboard.

Audio Analysis Pipeline:

Raw Audio (WAV/FLAC)
    |
    v
Spectrogram Conversion
    |-- Short-time Fourier Transform
    |-- Mel-frequency scaling
    |
    v
CNN Feature Extraction
    |-- Low-level: tempo, beats, segments
    |-- Mid-level: energy, valence, danceability
    |-- High-level: genre classification, mood
    |
    v
Feature Vector (128-256 dimensions)
    |-- Stored in feature database
    |-- Used for audio-based similarity search
    |-- Powers "song radio" and auto-generated playlists

Microservices and the Squad/Tribe Model

Spotify’s organizational structure became as influential as its technology. The squad/tribe model — a way of organizing engineering teams around microservices — was widely adopted across the tech industry.

How It Works

Spotify's Organizational Model:

Squad (6-12 people):
  -> Cross-functional team: backend, frontend, ML, design
  -> Owns a specific feature or system end-to-end
  -> Has its own microservice(s)
  -> Example: "Search Squad" owns the search service

Tribe (multiple squads, 40-150 people):
  -> Collection of squads in a related area
  -> Example: "Music Discovery Tribe" contains:
     - Search Squad
     - Discover Weekly Squad
     - Radio Squad
     - Browse Squad

Chapter (cross-squad, same discipline):
  -> All backend engineers across squads in a tribe
  -> Share best practices, code standards
  -> Chapter lead does coaching and hiring

Guild (cross-tribe, interest-based):
  -> Voluntary communities: "Web Performance Guild"
  -> Share knowledge across the whole company

Each squad owns its microservices completely — development, deployment, monitoring, and on-call. This autonomy means squads can deploy independently, choose their own tech stack (within reason), and move fast without coordinating with other teams.

The model has tradeoffs. Autonomy leads to duplication — multiple squads might build similar internal tools. Spotify addressed this with a platform team that provides shared infrastructure (logging, monitoring, deployment pipelines) so squads focus on product logic rather than reinventing infrastructure.

Backstage: Developer Portal

Spotify built Backstage, an internal developer portal, to manage the complexity of hundreds of microservices owned by autonomous squads. Backstage provides a catalog of every service, its owner, documentation, and health status. They open-sourced it in 2020, and it has become the dominant developer portal platform in the industry.

Event-Driven Architecture

Spotify processes billions of events per day — song plays, skips, searches, playlist modifications, ad impressions. These events drive everything from recommendations to billing to A/B test analysis.

Event Pipeline

Event-Driven Architecture:

Event Producers:
  - Client apps (play events, skip events, UI interactions)
  - Backend services (playlist updates, user changes)
  - Infrastructure (deployment events, errors)

Event Bus (Google Cloud Pub/Sub + Kafka):
  -> All events published to topic-based channels
  -> Events are immutable, append-only
  -> Retained for 7-30 days (depending on topic)

Event Consumers:
  +---> Real-Time Processing (Apache Beam / Cloud Dataflow)
  |       -> Listening activity feed ("Friend Activity")
  |       -> Real-time play count updates
  |       -> Fraud detection (bot plays)
  |
  +---> Batch Processing (Cloud Dataproc / Spark)
  |       -> Daily listening reports
  |       -> ML model training data
  |       -> Royalty calculations
  |
  +---> Analytics Warehouse (BigQuery)
          -> A/B test analysis
          -> Business intelligence dashboards
          -> Creator analytics (Spotify for Artists)

Royalty Calculation

Every song play generates a royalty payment to rights holders. This is not a simple per-play payment — it is a complex calculation based on the user’s subscription tier, country, and the total play share across all songs in that market.

Royalty Calculation (simplified):

1. Collect all play events for a month per market
2. Calculate total revenue per market:
   revenue = (premium_subscribers * price) + ad_revenue

3. For each song:
   song_share = song_plays / total_plays_in_market
   song_royalty = song_share * revenue * royalty_rate

4. Split royalty among rights holders:
   - Record label: ~55%
   - Publisher/songwriter: ~15%
   - Spotify: ~30%

This "pro-rata" model means every play of every song
must be accurately counted. Event processing
reliability is critical — lost events mean lost royalties.

Offline Mode: Intelligent Pre-Downloading

Spotify Premium users can download songs for offline listening. The system behind this is more sophisticated than simply downloading files.

How Offline Mode Works

Offline Download System:

Manual Downloads:
  User marks playlist for offline
    -> Client estimates storage required
    -> Downloads at current quality setting
    -> Encrypted files stored locally (DRM)
    -> Files periodically re-validated (license check)

Intelligent Pre-Download:
  Spotify predicts what you will listen to next:
  
  1. Songs in your current queue
  2. Songs you play frequently at this time of day
  3. Discover Weekly / Release Radar (download Monday morning)
  4. Podcasts you subscribe to (new episodes)
  
  Pre-downloaded when:
  - Connected to WiFi
  - Device is charging
  - Sufficient storage available

Storage Management:
  If device storage is low:
    -> Remove songs not played in 30+ days
    -> Reduce quality of cached songs
    -> Keep most-played songs at highest quality
    -> Show user notification before deleting

The intelligent pre-download is a significant competitive advantage. A user who opens Spotify in airplane mode can often play their usual music because the app predicted and cached it during the last WiFi session.

DRM and Encryption

Downloaded songs are encrypted with Widevine DRM. The encryption key is tied to the user’s account and device. If the user cancels their subscription, the key expires and the cached files become unplayable. The client checks license validity every 30 days — so offline mode works for up to 30 days without internet access.

Infrastructure: Google Cloud Migration

Spotify completed a major migration from on-premises data centers to Google Cloud Platform (GCP) between 2016 and 2018. This was one of the largest cloud migrations in history.

Why Google Cloud

Spotify chose GCP over AWS for several reasons:

• BigQuery — Spotify’s analytics needs are enormous. BigQuery’s serverless, petabyte-scale SQL analytics matched their workload better than AWS Redshift at the time.
• Cloud Dataflow — Apache Beam on managed infrastructure simplified their event processing pipeline.
• Data infrastructure — Google’s expertise in large-scale data processing aligned with Spotify’s core competency (ML-driven recommendations).
• Networking — Google’s private global network reduced inter-region latency for their globally distributed backend.

Technology Stack:

Languages:     Java (backend services), Python (ML, data),
               JavaScript/TypeScript (web client)
Cloud:         Google Cloud Platform
Databases:     Cloud Bigtable, Cloud Spanner, PostgreSQL (Cloud SQL),
               Cassandra (being migrated)
Caching:       Memcached, local caches
Messaging:     Google Cloud Pub/Sub, Apache Kafka
Processing:    Cloud Dataflow (Beam), Cloud Dataproc (Spark)
Analytics:     BigQuery
ML:            TensorFlow, custom models on Cloud ML Engine
Storage:       Google Cloud Storage (audio files)
CDN:           Google CDN + Fastly
Orchestration: Kubernetes (GKE)
Developer:     Backstage (open-sourced developer portal)

Key Takeaways

Spotify’s architecture demonstrates several principles for building large-scale content platforms:

• Audio streaming has different constraints than video. Sub-200ms start time and gapless playback require aggressive pre-fetching and buffer management. You cannot simply use DASH/HLS protocols designed for video.
• Recommendation is the moat. Discover Weekly, Release Radar, and Daily Mixes are what keep users on Spotify instead of Apple Music or YouTube Music. The combination of collaborative filtering, NLP, and audio analysis creates recommendations that are difficult to replicate.
• Organization shapes architecture. The squad model is not just an org chart — it is an architectural constraint. Autonomous squads naturally build loosely-coupled microservices because that is what enables independent deployment.
• Events are the source of truth. In an event-driven architecture, the events themselves (user played song X at time T) are the primary data. Everything else — dashboards, recommendations, royalties — is a derived view. This makes the system auditable and replayable.
• Offline mode is a feature, not an afterthought. Intelligent pre-downloading transforms a connectivity limitation into a competitive advantage. The ML that powers Discover Weekly also powers what songs to cache on your device.

When you press play and a song starts in under 200 milliseconds, that instant response comes from an access point that routed your request to a CDN edge, a buffer that was already filling before you finished choosing, and — if you are lucky — an audio file that was pre-downloaded to your device because an ML model predicted you would want to hear it. All of this while another set of models learns from your listening patterns to build next Monday’s Discover Weekly playlist.