Design Spotify

• POST /playback with { trackId, deviceId, quality } returns { cdnUrl, expiresAt, wrappedKey, bitrate }.
• POST /offline/licenses with { trackIds, deviceId } returns keys bound to the device, valid for 30 days.
• PUT /devices/:deviceId/state stores the current track and position for cross-device resume.

Each request is a few cache lookups (user tier, track rights, key), so a modest fleet handles tens of thousands of authorizations per second. Rights and keys are cached in memory because they change rarely.

Separating authorization from delivery means the backend handles one small request per track while the CDN handles megabytes of audio. Proxying audio through our own servers would allow tighter control but would multiply egress cost and latency. Offline licenses expire so a cancelled subscription stops working within 30 days without remote wipe.

Listening is heavily skewed: a small fraction of tracks accounts for most plays, so edge hit rates above 95% are typical. The regional shield tier collapses edge misses so the origin sees a tiny fraction of traffic. Clients also keep a local cache of recently played tracks, which removes a large share of repeat requests entirely.

Short chunks or byte-range requests let playback start after the first few hundred kilobytes and let the client switch bitrate between chunks on a weak network. Full adaptive streaming manifests like HLS add little for audio because a single bitrate rarely stalls; range requests on one file per bitrate keep the client simple.

• tracks(track_id, title, album_id, artist_ids, duration_ms, isrc, available_countries)
• albums(album_id, title, artist_id, release_date, cover_url)
• artists(artist_id, name, genres, follower_count)

Catalog reads are extremely cacheable, since metadata changes only on ingestion. The search index is rebuilt continuously from the catalog change log and replicated per region so queries never cross oceans. Popularity signals are refreshed daily into the index as a ranking field.

Country availability is stored on the track and applied as a search filter, rather than keeping a separate index per country, which would multiply storage by roughly 180. The filter costs a little query time but keeps one index to maintain.

• POST /playlists creates a playlist.
• PATCH /playlists/:id with { baseRevision, ops: [add, remove, move] } applies edits.
• GET /playlists/:id?offset=&limit= returns a page of tracks.
• PUT /playlists/:id/followers follows a playlist.

• playlists(playlist_id, owner_id, name, revision, is_collaborative, updated_at)
• playlist_tracks(playlist_id, position, track_id, added_by, added_at)

Most playlists are small and edited rarely. Editorial playlists with millions of followers are read heavy and served from cache, invalidated on each revision bump.

Optimistic concurrency with a revision number is enough for collaborative playlists, because conflicting edits are rare and the client can rebase simple add, remove, and move operations. A real-time CRDT would handle concurrent edits more gracefully but is unnecessary for this edit rate.

• play_events(event_id, user_id, track_id, country, ms_played, started_at, offline)
• daily_plays(track_id, country, day, play_count, rights_holder_id)

At roughly 3 billion plays per day (about 35,000 events per second on average), the stream is partitioned by user id. Deduplication keeps a window of seen event ids per partition, and offline events arriving days late are accepted into the correct day's partition.

Royalty counts are computed in batch from the raw event log rather than from live counters, so any bug can be fixed and the day recomputed for audit. Live counters on the hot path would be cheaper to read but impossible to correct after the fact.