Media & streaming, an interactive architecture walkthrough
Music streaming service: how the architecture works
How a music streaming service pre-encodes tracks into encrypted segments, checks rights before playback, and turns play events into royalties.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A music streaming service lets subscribers search a catalog of millions of tracks and play any of them within a second or two, online or offline. Tracks arrive from record labels with metadata and per-country rights, are transcoded once into several codecs and bitrates, split into short encrypted segments, and served from a CDN.
When a user presses play, a playback service checks their plan and country, returns segment URLs, and a license service issues the content key to the player's DRM module. Players prefetch the next track and cache recent ones. Playlists live in a store partitioned by user, and play events stream into listening history, royalty reporting and recommendations. This is a simplified learning design, not any company's production system.
Trade-offs and what changes at scale
Pre-encoding every track at several bitrates multiplies storage but makes playback simple and cacheable. DRM and per-country rights are required by label agreements and add a license step before playback. Offline downloads need the same keys with an expiry, so devices must check in periodically. Audio files are small compared with video, so the CDN cost is driven by the long tail of rarely played tracks rather than by bandwidth peaks. At larger scale the event pipeline matters as much as playback, because play counts determine royalty payments.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
Record labels send audio masters and metadata through Label Deliveries, and the Ingest Service checks it and stores tracks, artists and per-country rights in the Catalog DB. Rights decide where a track may play, so they are part of the catalog.
The Transcoder encodes each track once into several codecs and bitrates, split into short encrypted segments in the Audio Store. A track is encoded at ingest so playback never waits for encoding.
A listener searches from the Mobile Player, and the Search Service queries an index of tracks, artists and playlists. Search reads its own index, never the catalog database.
Pressing play asks the Playback Service for the track, which checks the user's plan and country with the Entitlement Service and returns segment URLs for a suitable bitrate. Free and paid plans differ here, in which bitrates are offered.
The player's DRM module asks the License Service for the content key, which is issued only to entitled users and devices. Segments on the CDN are useless without that key.
The player downloads segments from the Audio CDN and starts playing after the first one arrives, switching bitrate if the network changes. Popular tracks are almost always served from CDN cache.
The Mobile Player prefetches the start of the next track in the queue and keeps recently played tracks in a local cache. That makes skips feel instant and saves data on repeat plays.
Playlists and liked songs are stored by the Playlist Service in the Library Store, partitioned by user. Each user's library is read as one partition, which keeps it fast however large the catalog is.
Players send start, skip and completion events to Play Events, buffering them while offline. Offline plays still count once the device reconnects.
Royalty Reporting counts qualifying streams per track and rights holder, using the events' own timestamps and de-duplicating repeated uploads. Those counts become the payments to labels and artists, so they are audited, not estimated.
Recommendations reads Listening History to build daily mixes and radio stations, and writes them as playlists. Generating them in batches keeps model work off the playback path.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (20 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Catalog Ingestiondomain
- Audio Store: encrypted encodings (s3)
- Catalog DB: tracks, albums, artists, rights (postgresql)
- Ingest Service: validates metadata and territories
- Label Deliveries: masters, metadata, rights
- Transcoder: Opus/AAC at several bitrates
Clientslayer
- Mobile Player: streams, caches, plays offline
- Web Player: MSE playback with EME
Library & Searchdomain
- Library Store: playlists partitioned by user (cassandra)
- Playlist Service: playlists and liked songs
- Search Index: catalog and playlists (elasticsearch)
- Search Service: tracks, artists, playlists
Playbackdomain
- Entitlement Service: plan, region, offline rights
- License Service: content keys for entitled users
- Playback Service: track -> segment URLs and key
Edgelayer
- API Gateway: auth, entitlements, routing
- Audio CDN: encrypted audio segments
Listening Datadomain
- Listening History: plays per user and track (clickhouse)
- Play Events: starts, skips, completions (kafka)
- Recommendations: daily mixes and radio
- Royalty Reporting: counts qualifying streams per rights holder
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Netflix-style video streamingHow a streaming service encodes each title into many bitrates, caches it near viewers on a CDN, and personalises what each person sees.
- Video sharing platform (YouTube-style)How a video platform takes resumable uploads, encodes segments in parallel into several renditions, and serves them via a CDN with adaptive bitrate.
- Photo sharing platformHow a photo sharing platform takes uploads straight to object storage, resizes them in the background, and builds follower feeds from cached post ids.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.