System Design for PMs: The Services and Data Stores Behind Spotify

Walk the interviewer through how you would architect Spotify's server side: the main services, where the catalog, user data and audio files are stored, and how requests travel through the system. Pitch the depth at a product manager's technical round rather than production code. ```hint Size it before you draw Estimate how much audio leaves the system each day and how many small requests arrive each second, and let the difference between the two shape the design. ``` ### Clarifying Questions - Which capabilities are in scope: search and playback only, or also playlists, recommendations, podcasts, offline downloads and the ad-supported free tier? - Should I design for today's global scale, or for an early version that has to grow into it? - How deep should I go: boxes and data flows, or also storage choices and rough capacity numbers? - Is moving playback between devices, such as starting on a phone and continuing on a speaker, part of the design? ### What a Strong Answer Covers - A stated scope with functional and non-functional requirements, such as time to first audio and availability - Rough scale estimates and what they imply for the design - The main components and how a play request flows from the client to audio - Storage choices for catalog metadata, user data, audio files and listening events - Scaling, failure handling and the product trade-offs, including cost, licensing and consistency ### Follow-up Questions - A hugely popular artist releases an album at midnight. What breaks first, and how do you prepare? - How would you support offline downloads that stop working when a subscription lapses? - Where does the recommendation pipeline get its data, and what happens to the home screen if it fails?