Music streaming - three minutes of audio, played a billion times

Why this design

Music streaming looks like video streaming with smaller files, and the smaller files are exactly why it is a different problem. A track is about 4 MB, so delivery collapses into "put it on a CDN and prefetch the next one", and the interesting system is the one underneath: every play is a ledger entry in a monthly pro-rata royalty split, reported by a client you do not control, sometimes weeks late. Interviewers use it to see whether you notice that the hard part moved.

What you will learn

• Why a 4.2 MB track can be prefetched whole, so gapless playback and instant skips are a client decision, not an adaptive-bitrate one.
• Why playback starts with a licence check by territory, not with a byte.
• Why a play only counts at 30 seconds, and why the client is the one that measures it.
• Why the public play counter and the royalty ledger are different systems with different numbers.
• Why play events are deduplicated by a client-minted play_id, because offline phones retry for days.
• Why pro-rata royalties make stream fraud everyone's loss, not the platform's.

How to read this board

1. Press play once: the walkthrough follows one play from the button to a rights holder's statement.
2. PLAY: licence, signed URL, CDN, prefetch.
3. COUNT: the client's report, the 30-second rule, the fraud filter and the ledger.
4. DATA MODEL: the ledger as a table, and the royalty lines it closes into.
5. Then pages 1 to 6 in order: requirements, capacity, storage, availability, how it works, deployment.

Two products share one button. The listener wants music now; the rights holder wants an accurate count of how many times it played.

Ask these before designing

• How is a royalty computed? Pro-rata (a share of the whole pool) or user-centric (each subscriber's fee split among what they played)? Pro-rata is the industry default and is what makes fraud a zero-sum theft between artists.
• What counts as a play? The common rule is 30 seconds of audio actually heard. Skips under 30 s are product signals, not royalty events.
• Is offline listening supported? If yes, plays arrive late, and the ledger needs a late-arrival window and a restatement policy.
• Territories: a track can be licensed in Germany and not in Japan. Is the catalogue per country? (It is.)
• Free tier with ads? Changes the pool, not the architecture.

Functional

• Search and browse a catalogue of 100M tracks.
• Play a track within 250 ms of pressing play; next track plays gaplessly.
• Download for offline play, with licence expiry.
• Record qualifying plays exactly once, per listener, per territory.
• Show a public play count per track.
• Close a monthly royalty statement per rights holder.

Non-functional

• Time to first audio p95 under 250 ms on a warm client, 600 ms cold.
• No double-counted plays. A retried batch must not inflate a statement.
• Late plays accepted for 30 days, restated into the next statement.
• Playback availability 99.95%; the ledger may lag by hours but must never lose an event.
• Public counter may be up to an hour stale and is explicitly approximate.

Out of scope

Podcasts and video, recommendation models, the ad server, lyrics, social features, label onboarding contracts.