Music Streaming Service · Approach · designlab

Music Streaming Service · Approach · designlab

Analysis

Reason about the problem

Approach

Turn it into a plan

Solution

The complete design

01 · Develop the design

Plan the design

Serve immutable audio from object storage through a CDN, serve metadata from a cached database, and record play events on a stream that workers aggregate off the request path.

Stage 1

Split bytes from metadata

Audio files and catalog metadata have very different shapes. Put audio in object storage behind a CDN and keep metadata in a cached database.

Stage 2

Keep plays off the hot path

Write play events to a stream and let workers aggregate them. Playback must not wait for royalty accounting.

Stage 3

Count each play once

Give every play a client-generated id so retries and duplicates can be removed before royalties are computed.

02 · Work through the method

Step-by-step approach

Store each track in several encodings in object storage under content-addressed keys; the CDN caches popular files near listeners.
The API serves catalog and playlist metadata through a cache in front of the metadata database; playlists are small documents read far more than written.
Clients send play events with a unique play id to the API, which appends them to an event stream and returns immediately.
Analytics workers consume the stream, deduplicate by play id, apply the listen threshold, and write aggregates to object storage for royalty and recommendation jobs.

03 · Justify the choices

Why this approach works

Where should audio bytes be served from?

From a CDN backed by object storage

Audio files are large, immutable and popular in a long tail; a CDN keeps hot tracks near listeners and object storage holds the rest.

How should play events be recorded?

Appended to an event stream that workers aggregate asynchronously

Royalty counting needs durability but not playback latency. A stream absorbs bursts and lets aggregation lag without blocking listeners.

What makes a play countable for royalties?

A deduplicated event with a play id, listened past a threshold

Retries and seeks produce repeated requests; an idempotent play id and a listen threshold keep counts honest.

04 · Plan the evidence

Validation strategy

Playback continues while the analytics workers are stopped.
A retried play event is counted once.
A playlist edit is visible on the next read after invalidation.
A burst of plays grows the stream backlog, which drains after the burst.

Trade-offs to explain

A CDN hit ratio depends on catalog popularity; long-tail tracks still reach object storage.
Asynchronous counting means royalty dashboards lag by minutes.
Caching metadata trades freshness for load; playlist edits need explicit invalidation.

Read the detailed solution Build my design