Design Spotify

Users judge music apps by how fast the song starts after a tap or skip. The levers: first, the on-device cache. Clients keep a large encrypted cache (several GB) of recently played files, and because people replay the same songs a lot, a big fraction of plays never touch the network. Second, prefetching: while track N plays, download the first part of track N+1 (and for shuffle, the chosen next track), so a skip starts from memory. Third, a small first request: fetch only a few seconds of audio with an HTTP range request so decoding starts fast, even on a slow mobile network, then continue streaming. Fourth, CDN placement: audio files are immutable and encrypted, so they can sit on multiple commercial CDNs with high hit rates; the client is given more than one host and retries elsewhere on failure. Pick the bitrate by network and plan (24 kbps on a poor connection, 160 kbps normal, 320 kbps Premium). Files are encrypted with per-file keys, and keys are delivered separately; the CDN never sees a playable file. Spotify originally used peer-to-peer to offload bandwidth but dropped it in 2014 once CDN costs fell; mentioning why P2P stopped being worth it shows judgement.

Royalties are paid per stream, so counts must be complete and not inflated. The client creates a unique event id for each event and persists events locally until the server acknowledges them, which means at-least-once delivery from client to server. The server writes to a durable event bus (Kafka or Pub/Sub) before acknowledging. Downstream, the counting job deduplicates by event id over a window long enough to cover late arrivals; offline plays can arrive days later, so dedup and attribution use the event's own play timestamp, and daily reports are finalised after a grace period. A play counts as a stream after 30 seconds. Fraud filtering looks for unnatural patterns: the same tracks looped by many fresh accounts, plays from data-centre IPs, or perfectly regular timing. Store raw events immutably in the data lake and compute reports in batch, so any reporting bug is fixed by re-running the job. Real-time numbers (artist dashboards) come from a streaming path that is allowed to be approximate.

A playlist is an ordered list of up to ~10,000 items. Store it as a sequence of items plus a snapshot id that changes on every edit; clients cache the playlist with its snapshot id and ask 'has it changed since snapshot X?', which is cheap and saves bandwidth for large playlists. Edits are small operations (add, remove, move) applied in arrival order with a rebase against the latest snapshot, which is enough for collaborative playlists where conflicts are rare and harmless. Reads are extremely skewed: a top editorial playlist can have tens of millions of followers and be opened thousands of times per second. Serve it from a cache keyed by (playlist_id, snapshot_id); because the snapshot is immutable, cached copies never need invalidation, only the 'current snapshot' pointer does. Follower counts are counters maintained asynchronously, not computed on read. Market availability is applied at read time, so a track not licensed in India is greyed out instead of the playlist being duplicated per country.

Most recommendations are precomputed. Batch pipelines on the data lake build user and track embeddings from listening history, playlist co-occurrence (two songs often in the same playlists are similar), and audio features; they then generate per-user outputs like a weekly discovery playlist, daily mixes and home shelves, and write them to a key-value store keyed by user id. At request time, the home service reads the precomputed shelves and adjusts them with session context (time of day, recently played, device such as car or smart speaker). This keeps the online path cheap and resilient: if the pipeline is late, users see yesterday's shelves. New users and new releases are the cold-start problem: use onboarding choices, language and region (Punjabi, Tamil, Bollywood are huge separate audiences in India), and popularity within similar listeners.

P2P cut costs when bandwidth was expensive, but hurt mobile battery and data plans and added complexity. Commercial CDNs became cheap enough that serving everything from CDN plus a big client cache is simpler and faster.

Precomputed lists are cheap, stable and easy to evaluate, but react slowly. Real-time models react to the current session but cost more per request. A hybrid gives most of the benefit: precompute candidates, rerank lightly at request time.

Royalty counts must be exact and auditable, so they come from deduplicated batch jobs. Live artist dashboards use a separate approximate stream pipeline. Mixing the two leads to either slow dashboards or wrong payouts.

Playlists change rarely and conflicts are mild, so snapshots plus rebased operations are enough. A CRDT would add complexity without a real user benefit.

A major album drop at midnight sends millions to the same tracks. Pre-warm CDNs with the new files, cache metadata and the album page, and make sure the first-chunk requests are served from edge.

Millions of reads on the same playlist. Immutable snapshots cached at the service and CDN layer remove the hot key problem.

Hundreds of thousands of events per second with spikes after mass reconnects (morning commute, offline uploads). Batch events on the client, compress, partition the bus by user id and autoscale consumers on lag.

The client keeps playing from its buffer and cache, retries other CDN hosts, and lowers the bitrate. Offline downloads keep working with cached keys until the offline licence expires (~30 days without reconnecting).

Clients keep events in a local queue and retry with backoff. Events have unique ids, so retries cannot double count.

Serve the previous day's shelves and mixes. Users rarely notice a one-day delay.

Serve from replicas, reduce query complexity (skip fuzzy and personalisation) and keep popularity-ranked results available.