Design Spotify

Stream 100 M tracks to 600 M listeners with sound in 200 ms, offline downloads, regional licensing, and every play counted for royalties.

Last updated 2026-10-26. Difficulty: hard. Patterns: prefetching, licensing, offline, counting, playlists. Reported at Spotify, Apple, Amazon, Google, Meta, TikTok.

Functional requirements

• Search the catalogue. Tracks, artists and albums, as you type and tolerant of typos, ranked by relevance and popularity, and showing only what is playable in the listener’s country.
• Play a track. Sound within ~200 ms of pressing play or of the previous track ending, no silence between tracks of a live album, and no stalls mid-track.
• Free and Premium tiers. Free plays ads between tracks and caps quality at 160 kbps; Premium has no ads, up to 320 kbps and downloads. The tier is checked on every play, not only at login.
• Regional licensing. A track can be playable in Sweden and not in Japan, Premium-only for two weeks after release, or taken down tomorrow. Every play obeys the rules for that country and tier at that moment.
• Playlists synced across devices. Ordered lists of up to 10,000 tracks edited from phone, desktop and web, including collaborative playlists that several people edit at once. No edit is ever lost.
• Offline downloads for Premium. Download playlists and play them with no network. Downloads stop playing if the subscription lapses or the device stays offline for more than 30 days.
• Count plays for royalties. A play counts once it passes 30 seconds. Counts per track, country and tier become monthly statements for labels and publishers, so they must be exact, deduplicated and defended against fraud.
• Personalised weekly playlist. A fresh 30-track playlist for every user every Monday, generated in batch.
• Out of scope. Encoding the catalogue (a simpler version of the pipeline in Design YouTube), podcasts and video, lyrics, social features, ad targeting and the ad auction, and billing.

Non-functional requirements

• Scale (600 M MAU · 250 M DAU · 10 M concurrent streams). A catalogue of 100 M tracks. Sessions are long and continuous, so most plays are the next track in a queue rather than a fresh tap.
• Time to first audio (p90 < 200 ms). Measured from the tap, or from the end of the previous track, to the first sample out of the speaker. A cold tap only meets it on an edge cache hit over warm connections; prefetching makes queued tracks near zero.
• Gapless playback (0 ms between tracks). Live albums and DJ mixes must flow sample to sample, so the next file must be on the device and decoding before the current one ends.
• Licensing correctness (takedowns < 15 min). Never start a play the rights do not allow in that country and tier. New plays stop within seconds of a change; already issued URLs expire within 15 minutes.
• Royalty accuracy (exactly once, reconciled). The requirement that drives the hardest trade-off. Plays come from clients we do not control, arrive weeks late from offline phones, get retried and get faked, yet each month’s statement must count every real play once and reconcile with zero differences.
• Availability (99.99 % playback). Playback depends only on the resolve call and the CDN. Downloads must play with no network at all for up to 30 days.
• Playlist sync (other devices < 5 s). Concurrent edits from several devices and collaborators converge to the same order everywhere, and none is lost.

Back-of-envelope estimates

• Play starts at peak: ~48 k/s (~100 k/s with skips). 10 M concurrent streams ÷ 210 s per track ≈ 48 k/s if nobody skips; skips roughly double it to ~100 k/s. Each one is a rights check and a signed URL, so the playback service is sized for this, not for bytes.
• Catalogue storage, every rung: ~1.6 PB. One 210 s track at 24, 96, 160 and 320 kbps is 0.63 + 2.5 + 4.2 + 8.4 ≈ 15.75 MB. 100 M tracks × 15.75 MB ≈ 1.6 PB, comparable to a video service’s whole catalogue, but spread over 400 M small files instead of a few hundred thousand large ones.
• Peak egress: ~1.6 Tbps. 10 M streams × 160 kbps average = 1.6 Tbps, about 1 % of a large video service at peak. Two commercial CDNs carry this comfortably: bandwidth is not what makes this design hard.
• Hot head at the edge: ~16 TB. Assume the 1 M most-played tracks (1 % of the catalogue) carry most plays. 1 M × 15.75 MB ≈ 16 TB at every rung, small enough to keep in every edge PoP. The other 99 M tracks cannot be everywhere, so a cold tap on one of them pays a trip to a shield or to origin.
• Play events per second: ~87 k/s avg · ~150 k/s peak. 6 M average concurrent streams × 86 400 s ÷ 210 s ≈ 2.5 B plays/day, 10 per daily user. Three events per play (start, 30-second mark, end) = 7.5 B/day ≈ 87 k/s, ~150 k/s at peak. This is the stream the money is computed from.
• Raw play log per year: ~1.4 PB. 7.5 B events × ~500 B = 3.75 TB/day ≈ 1.4 PB/year. Kept immutable for years in cheap object storage, because rights holders audit statements and every count must be recomputable from the raw events.
• Rights data for every play check: ~10 GB. Three territory bitmaps per track (ad-supported, subscription, offline) over ~250 territories is 750 bits; with the next scheduled change that is ~100 B per track, so 100 M tracks ≈ 10 GB. It fits in memory on every playback instance, which makes the check a bit lookup rather than a database call.
• Playlist storage: ~10 TB. Assume 5 B playlists × 50 items × ~40 B (item id, track id, position key, added by, added at) ≈ 10 TB, plus op logs. Small for a sharded store: the hard part is concurrent edits, not size.

Components

• Audio CDN (two CDNs · head at every edge): Serves encrypted, immutable audio files by signed URL. Popularity-tiered: the ~1 M most-played tracks (~16 TB at every rung) are pre-warmed in every edge, the middle of the tail sits in regional shields, and the deep tail is fetched from origin on a miss. It checks only the URL’s signature and expiry and knows nothing about licensing; its cache key ignores the signature so all listeners share one copy.
• Audio origin (object storage · 4 rungs): Every track at 24, 96, 160 and 320 kbps, ~1.6 PB, as immutable files named by content hash and encrypted with a per-file key. Only CDN shields read from it. Because names never change, files are cached for a year and nothing is ever invalidated.
• Search service (inverted index · market filter): An inverted index over ~150 M tracks, artists and albums, fed from the catalogue by change data capture. Each document carries its territory bitmap, so the listener’s market is a filter applied before ranking, and ranking combines text match with popularity in that market and a personal boost. Serves typeahead at ~75 k queries/s at peak from replicas in each region.
• Offline licenses (device keys · 30-day expiry): Registers devices (at most 5 per account) and issues offline licenses: each downloaded file’s key wrapped with a key that lives in the device’s secure hardware, valid for 30 days. Renewal re-checks tier and rights and returns tracks to delete. It never serves bytes.
• Listener app (phone · desktop · web): Plays audio, keeps the queue, prefetches the first 30 seconds of the next track and decodes it early for gapless transitions, and caches the first seconds of tracks the listener is likely to play. Picks a quality rung per track at play time, stores encrypted downloads, and keeps play events on disk until the server acknowledges them.
• API gateway (auth · routing · push): Terminates TLS for every API call, validates the session token (which carries user id, tier and home country) and routes to services. Holds a persistent connection per active device for small push messages such as "playlist changed". Audio bytes never pass through it.
• Playback service (entitlement · signed URLs): Turns "play track X" into "fetch file F from these CDN hosts". Checks rights for the listener’s country and tier against an in-memory copy of the compiled rights (~10 GB), picks the file for the rung, and signs URLs that expire in 15 minutes. Stateless and scaled for ~100 k resolves/s; for Free listeners it also schedules ad breaks, which are just more audio files.
• Catalogue & rights (deals by territory · tier · window): Source of truth for tracks, their files and the deals that govern them: per recording, the territories, commercial models (ad-supported, subscription, download) and start and end dates delivered by rights holders. A compiler turns deals into per-track bitmaps plus the next scheduled change and streams them to every playback instance within seconds.
• Rights holders (labels · publishers): Deliver releases and deal terms as structured feeds (DDEX-style) and receive monthly usage statements and payments. They audit statements, so every number must be recomputable from raw data.
• Playlist service (per-playlist op ordering): Accepts edits as operations (insert after item X, move, remove) with the version the client saw, orders them per playlist with a conditional append, assigns fractional position keys, and pushes the new version to other devices, which pull the ops they are missing. The weekly personalised playlist is written through the same API.
• Playlist store (op log + snapshots): Per playlist: a header (owner, collaborators, version), items with stable ids and position keys, an append-only op log keyed by (playlist id, version), and a snapshot every 100 ops. Needs conditional writes on the version, so Spanner, or Cassandra with lightweight transactions. ~10 TB of items.
• Event log (Kafka / Pub/Sub · key = play id): Durable log of play, ad and app events from every client, ~150 k/s at peak, acknowledged only once persisted. Keyed by play id, so a hit single spreads across partitions. Each hour is landed as immutable Parquet with control totals, the raw evidence every count is recomputed from.
• Play validation (dedupe · 30 s rule · fraud): Dedupes events by play id, applies the 30-second rule, verifies that each online play carries a play token the playback service signed, and scores plays for fraud. Labels every play as counted, short, duplicate, fraud-held or invalid, and feeds live dashboards. The only source of plays for royalties and recommendations.
• Royalty run (daily batch · reconciled): Each day recomputes exact qualified plays per (track, country, tier) from the raw log, deduplicated by play id over all history and attributed to the day each play happened. Refuses to publish unless every raw play id lands in exactly one bucket. Monthly, splits each market’s royalty pool by play share into statements; closed months are never edited, and late plays become adjustments.
• Weekly recs (weekly batch): Reads validated listening history, finds candidates from listeners with similar taste and from track embeddings, filters out tracks unavailable in the user’s market or already heard, and writes each user’s 30-track weekly playlist through the playlist service. The output is just another playlist, so sync, downloads and playback need nothing new.

User flows

1. Search, tap, hear it in 200 ms. The cold path is a search, one resolve call that checks rights and signs a URL, and one range request to the nearest edge. The warm path, which most plays take, has the next track on the device before the current one ends.
   1. The listener types a query; search returns tracks, artists and albums playable in their market. Typeahead sends a request per keystroke after a short debounce, ~75 k queries/s at peak. The market comes from the session token and filters on each document’s territory bitmap before ranking, so a track that cannot play never appears. Popularity in that market is part of the score, which is why typing "hello" shows the hit before 400 covers.
   2. The listener taps a track and the app asks the playback service to resolve it. The connection is already warm (HTTP/2 or QUIC), so this costs one round trip, ~40 ms on a phone. The app asks for a rung from tier, setting and network: 160 kbps on Free, 320 on Premium over Wi-Fi, 96 on a weak cellular link. It keeps that rung for the whole track.
   3. Playback checks the rights for this track, country and tier, and signs a short-lived URL. The check is a bit test in an in-memory copy of the compiled rights, kept fresh from the catalogue’s change feed, so it costs microseconds, not a database round trip. If this release is not licensed here but another release of the same recording is, playback swaps to it (relinking). The URL is an HMAC over the file path and an expiry 15 minutes out, so the CDN can verify it alone.
   4. The app requests the first bytes of the file from the nearest edge. Only ~32 KB, about a second of 320 kbps audio, is needed to start decoding: ~25 ms on a 10 Mbps link. The edge verifies signature and expiry, then serves from cache, where popular tracks are pre-warmed. On a hit, start-up is ~40 ms resolve + ~35 ms to the edge + ~25 ms transfer + ~40 ms decoder and audio output, about 140 ms.
   5. On a miss, the edge fetches from its regional shield, and the shield from origin. A deep-tail track adds 50 to 150 ms, the one case that misses the 200 ms target. It is rare by definition, and the next listener in that region hits the shield. Files never change, so there is nothing to invalidate.
   6. Thirty seconds before the track ends, the app resolves the next track in the queue and fetches its first 30 seconds. Most plays are the next track of an album, playlist or radio queue, so this is the path that matters most. When the current track ends the next one is already decoding, and trimming the encoder delay and padding from resolve makes the join gapless. The rest of the file is fetched as soon as it starts (~3 s at 10 Mbps); prefetching only ~600 KB caps the waste when the listener stops or skips.
   7. The app reports the play: started, passed 30 seconds, ended. Events are batched every few seconds and kept on disk until acknowledged, so a crash or a tunnel loses nothing. Each carries the play token from resolve as its play id, which makes a retried batch harmless. Playback never waits on this call.
2. Two people edit a collaborative playlist. Edits are operations on stable item ids, ordered once per playlist and synced as a log, so concurrent edits from phones, laptops and friends converge without losing anyone’s change.
   1. Alice’s phone inserts a track after a given item, based on version 41. The client sends an intention, not a new list: insert this track after item it_77. Naming a neighbour’s stable id rather than an index keeps the meaning intact while others edit. The base version tells the server what the client had seen.
   2. The playlist service appends the op with the next version and a position key between the neighbours. Position keys are strings that sort: between "a4" and "a5" it picks "a4V", so an insert or a move writes one row instead of renumbering up to 10,000. The append is conditional on the current version, which orders ops for one playlist even when two service instances race.
   3. Bob’s laptop moves an item to the top, also based on version 41; the service rebases it onto 42. The op names item ids, so it means the same thing after Alice’s insert and applies as version 43 without bothering Bob. The conflict rules are fixed: two moves of one item, the later version wins; an edit to a removed item is a no-op; equal keys tie-break on item id.
   4. Other devices and collaborators learn the new version and pull the ops they are missing. The push carries only the playlist id and version; each device asks for ops since its own version. A device too far behind gets the latest snapshot plus the short tail instead. Offline devices pull when they next start.
   5. Every 100 ops the service writes a snapshot of the ordered items. Snapshots bound how many ops anyone replays and let old ops be compacted. If keys have grown long from many inserts in one spot, the snapshot writer rebalances them in a single op that every device applies like any other.
   6. Each weekend, the recommendation job writes every user’s weekly playlist through the same API. It reads only validated plays, so bot traffic cannot train it. Each run replaces the items of a system-owned playlist as a new version: 600 M playlists over a weekend is ~3.5 k writes/s, throttled and staggered by time zone so each is ready on Monday morning local time. Devices sync, download and play it like any other playlist.
3. A superstar album drops at midnight. A scheduled spike: millions press play on the same 13 tracks as midnight rolls across time zones. The bytes are easy if they are placed in advance; the rights flip, the control plane and one very hot track in the event pipeline are where it can break.
   1. Days ahead, the label delivers the album with a release window per territory, and search indexes it hidden. The deal says available from 00:00 local time on Friday in every territory, for both tiers. The compiler records a scheduled change on each track, and the search documents carry an "available from" time, so the album is in the index but filtered out until it opens.
   2. The encrypted files are pushed to every edge before the window opens. 13 tracks × 15.75 MB ≈ 200 MB at every rung, trivial to place in every PoP. It is safe because no URL can be signed before the window and the files are useless without keys, which only resolve hands out.
   3. At local midnight in each country, playback instances start allowing the tracks. Each instance already holds the next scheduled change per track, so it flips at the exact second instead of waiting for a feed. Midnight rolling from New Zealand to Hawaii spreads the release into waves over a day rather than one global spike.
   4. Millions resolve the same tracks and search for the artist within minutes. Playback is stateless with rights in memory, so it scales by adding instances; it is pre-scaled for the known time, because autoscaling reacts in minutes and the spike arrives in seconds. The artist query is cached per market, and new-release and artist popularity stand in for the album’s own popularity, which is still zero.
   5. Every listener streams the same few files from edge caches. 5 M concurrent listeners on one track at 160 kbps is 800 Gbps, half our normal peak, all from edge memory. The cache key ignores the per-user signature, and shields coalesce misses, so origin sees about one request per file per region.
   6. Play events for one track flood the event log, spread by play id. Keyed by track id, one partition would take millions of plays an hour and fall behind. Keyed by play id the load spreads evenly, and dedupe still works because it only compares events of the same play. Per-track totals are summed in two stages: partial counts per partition, then a merge.
4. Download, listen on a plane, report later. Downloads are encrypted files plus a device-bound license that expires. Plays made offline are buffered with their own ids and counted when the phone returns, days later, exactly once.
   1. A Premium listener downloads a 200-track playlist; playback checks tier, offline rights and the device count. Offline is its own right: some deals allow streaming but not downloads in some territories. Tracks that fail come back with a reason, so the app greys them out instead of failing silently.
   2. The license service registers the device and returns the file keys wrapped for it, valid for 30 days. The device key pair is generated in the phone’s secure hardware (Android Keystore, Secure Enclave) and the private key never leaves it, so the wrapped keys are useless on any other device. A sixth device is refused until the user removes one; removing a device revokes its license at its next check-in.
   3. The app downloads the encrypted files from the CDN with ordinary signed URLs. 196 tracks × 4.2 MB ≈ 820 MB at 160 kbps, over Wi-Fi by default and resumable with range requests. They are the same files the CDN serves for streaming; it cannot tell a download from a stream and does not need to.
   4. In flight, the app plays from disk and records each play with an id it mints itself. With no network there is no play token, so the client creates a time-ordered UUID per play and queues the events on disk with the device time and a monotonic counter. A clock set backwards is caught by comparing with the latest server time the app has seen.
   5. Days later the phone reconnects and uploads the buffered events; a dropped connection makes it send one batch twice. The client deletes events only after a batch is acknowledged, so a retry resends the same play ids, which dedupe makes harmless. The upload also reports the device clock offset, so event times can be corrected.
   6. Validation dedupes the plays and assigns each to the day it was played, not the day it arrived. An offline play must be for a file in a license that device held at the time, which stands in for the play token as proof the play was possible. If that month has closed, the plays become an adjustment on the next statement, never an edit to a closed one.
   7. Before 30 days pass, the app renews its license, and renewal re-checks tier and rights. A user who dropped to Free has the license revoked and downloads stop. Taken-down tracks are listed for deletion. A phone that never comes back online stops playing downloads when the license expires: 30 days is the most anyone keeps music they no longer pay for.
5. The daily royalty run reconciles to zero. The background path where money is decided. Every play id lands in exactly one bucket, the totals reconcile against the raw log, and only then do counts become statements.
   1. Ingest lands each hour of raw events in an immutable store with control totals. When an hour closes, the ingest tier writes the event count and a checksum per partition. The batch later proves it read every event by matching them. Raw events are never edited; a correction is a new record.
   2. Validation labels every play: counted, under 30 seconds, duplicate, held for suspected fraud, or invalid. Fraud signals combine: listening hours per account beyond what a person can do, one track on repeat, accounts created in bulk, many accounts per device fingerprint or data-centre IP range, no searching or skipping. An online play without a valid play token is invalid outright. Held plays are quarantined, not deleted, so a false positive can be released before the month closes.
   3. The daily batch recomputes qualified plays per track, country and tier from the raw log. It dedupes by play id across all history, not a stream window, so an offline upload weeks late is still caught if it repeats. Plays are attributed to their event date. Recomputing from raw data every day, instead of trusting the stream’s running totals, is what makes the number auditable.
   4. Reconciliation checks that every raw play id is in exactly one bucket before anything is published. Distinct play ids in the raw log must equal counted + short + duplicate + fraud-held + invalid, per day and per partition, and raw event counts must match the ingest control totals. A difference of one blocks the run and pages someone: a late statement is a nuisance, a wrong one is a dispute.
   5. At month end, each market’s royalty pool is split by play share into statements for rights holders. The pool is a share of that market’s revenue per tier, divided pro rata by each track’s share of counted plays, then among recording and publishing owners. This is why fraud matters: fake plays do not create money, they take it from every other artist in the pool.
   6. Late offline plays and fraud reversals go into the next statement as adjustments. A closed month is never edited, as in a ledger: a correction is a new line that names the period it belongs to. Rights holders can audit any line back to raw events, because the raw log (~1.4 PB a year) is kept for years.

Deep dives

The theory behind it

• CDNs and edge computing: How a content delivery network works, push vs pull, cache keys and TTLs, what to put at the edge, edge functions and KV, and the pitfalls of caching dynamic content.
• Counting at scale: How to count likes, views, clicks and unique visitors at high volume: exact versus approximate counts, sharded counters, batching through streams, idempotent counting, HyperLogLog for uniques, windowed counts and reconciliation.
• Offline-first apps and sync: Designing apps that work without a connection and sync later: local-first storage, change logs and sync cursors, conflict resolution with last-writer-wins, merges and CRDTs, operational transformation, and keeping clients and server consistent.

Related

• Design Post Search
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit