Design a Music Streaming Service with Playlists, Search and Audio Delivery

You are asked to design a music streaming service similar to Spotify. Listeners sign up, search and browse a catalog of artists, albums and tracks, press play and hear audio within moments, and collect what they like into playlists they can edit and share. The interviewer in this round paid close attention to how the backend is divided. A design that kept users, playlists and track metadata as tables in one shared relational database was flagged as a weakness, so expect to justify each service you introduce and the data it owns. The prompt names only the product, so assume this standard scope: - Mobile, desktop and web clients serving a global audience. - Accounts and sign-in, catalog metadata and search, audio playback, and playlists (create, rename, delete, add, remove and reorder tracks, and view other users' public playlists). - Out of scope unless the interviewer asks: recommendations, subscription billing, artist upload tooling, royalty accounting and podcasts. ### Clarifying Questions - How many users, daily listeners and catalog tracks should the design target? - Which audio quality levels must be offered, and do they differ by subscription tier? - Is playback online only, or must users be able to download tracks for offline listening? - Do licensing rules make some tracks unavailable in some countries? - Can a playlist have several editors, and how large can a single playlist get? - How quickly must audio start after the user presses play? ### Part 1 — Requirements, estimates and APIs State the functional and non-functional requirements you will design for, estimate catalog storage and peak streaming bandwidth, and define the main client-facing APIs for search, playback and playlists. ```hint Separate the bytes from the metadata Estimate the audio files and the catalog metadata separately; the gap between the two numbers should shape the rest of the design. ``` #### What This Part Should Cover - Prioritized requirements, including availability and playback start-up latency - Order-of-magnitude estimates for audio storage, metadata size and peak egress, with the assumptions shown - Concrete endpoints with request and response shapes, including how a client starts playback and pages through a long playlist ### Part 2 — Service boundaries and data ownership Split the backend into services. For each one, say which data it owns, which kind of store you would keep that data in and why, and how other services obtain data they do not own: for example, how a playlist screen shows each track's title, artist and duration. ```hint Compare the access patterns Look at how often catalog entries, playlists, accounts and listening events are read and written, and how strictly consistent each one needs to be. ``` #### Clarifying Questions for this Part - Are separate teams expected to own and deploy different parts of the product independently? - Must a playlist reflect a change to a track's metadata (a corrected title, a removed track) immediately, or is a short delay acceptable? #### What This Part Should Cover - Domain-based services that each own their data, with no tables shared across services - A storage choice per domain justified by its read/write mix, scale and consistency needs - How data crosses service boundaries (batch lookups, caching, events) and what is allowed to be eventually consistent - The costs decomposition introduces and how the design keeps them contained ### Part 3 — Playback path, scaling and failures Trace what happens from the moment a listener presses play until audio is heard. Then explain how the system copes as listening grows, when a single track suddenly becomes extremely popular, and when a component fails. ```hint Follow the audio Ask which component actually delivers the audio bytes to the listener, and which decisions your own services still need to make before that can happen. ``` #### What This Part Should Cover - Authorization and availability checks before audio is served, and how the client is granted access to the files - How audio is encoded, stored and cached close to listeners to keep start-up fast - Handling of hot tracks, hot playlists and peak listening hours - Behavior when a cache, a service or a region fails, and what you would monitor ### What a Strong Answer Covers - Scope settled early, with estimates that actually drive design decisions - Clear service boundaries, each with an owned store chosen for its access pattern - A playback path that keeps application servers out of the bulk data path while still enforcing access rules - Playlist writes that stay correct under client retries and concurrent edits - Explicit trade-offs, especially the operational cost of several services versus one shared database - Failure handling and observability tied to what listeners actually experience ### Follow-up Questions - The interviewer argues that one database would be enough for a launch. How do you defend or adapt your decomposition? - How would you add offline downloads for paid users while still enforcing license expiry? - A track is pulled from the catalog for licensing reasons. What happens to every playlist that contains it? - How would you count plays accurately enough to pay artists, given that clients go offline and retry?