Music Streaming Service

Design a Spotify-like service. Listeners browse catalogs and playlists and stream audio files. Every play produces an event that must be counted for royalties and personalization, without slowing playback.

The service has a hot, cacheable read path and a steady write stream that must be durable but not fast. Mixing the two makes either playback slow or counting fragile.

A single API with one database works for a small catalog. It breaks when audio bytes and play writes share the database with catalog reads; separating storage, caching and the event pipeline removes each bottleneck in turn.

1. Serve track, album and playlist metadata with low latency.
2. Deliver audio files from storage close to listeners.
3. Record every play event durably for royalties and analytics.
4. Keep playback working when the analytics pipeline lags.

Workload: 20,000 reads/s, 2,000 writes/s, 300 B records, 200 ms read p99 target. These are exercise assumptions; the Solution includes capacity formulas.

Metadata reads are small and frequent; audio reads are large and sequential. Sending audio through the API servers would tie up their connections for minutes, so clients fetch audio directly from the CDN with signed URLs the API hands out.

A play event is a fact appended to a log. Workers can be added, paused or replayed from an offset without touching playback. Deduplication by play id makes the pipeline safe to retry.