# Design Music Search, Playlists, and Playback Controls Design the core application model and service interfaces for a music product. Users can search by song, artist, or album; create and edit playlists; and control a playback session with play, pause, and reset. Begin with a clear single-service design, then identify boundaries that would matter as usage grows. ### Constraints & Assumptions - A song can belong to an album and have one or more artists. - Search results must identify which entity matched and link to playable songs where appropriate. - Playlist ordering matters, and concurrent edits must not silently overwrite one another. - Play, pause, and reset must have defined behavior for repeated or out-of-order commands. - Media delivery details may be abstracted, but playback state and authorization may not. ### Clarifying Questions to Ask - Is search prefix, substring, or full-text, and what ranking signals are required? - Can playlists contain duplicate songs or be shared with other users? - Is playback state local to one device or synchronized across devices? - Does reset mean seek to the beginning while paused, or stop and clear the active track? ### Part 1: Domain Model and Interfaces Define the main entities, relationships, invariants, and APIs for search, playlists, and playback commands. #### What This Part Should Cover - Stable identities for songs, artists, albums, users, playlists, and playback sessions. - Ordered playlist entries with ownership and versioning. - Explicit playback state transitions and idempotent command semantics. ### Part 2: Search Explain how catalog changes become searchable and how a query across song, artist, and album fields is served and ranked. #### What This Part Should Cover - A canonical catalog store and a derived search index. - Entity-type-aware results, normalization, pagination, and freshness trade-offs. - Reindexing, deletion, and failure recovery. ### Part 3: Consistency, Testing, and Growth Describe concurrency controls, failure handling, observability, and where you would split the design if load increased. #### What This Part Should Cover - Optimistic concurrency or transactional edits for playlist ordering. - Playback-session ownership and command ordering. - Contract, state-machine, search-quality, and concurrency tests. - Metrics for search latency, index lag, edit conflicts, and invalid transitions. ### What a Strong Answer Covers - A coherent object and API design that satisfies all reported functions. - Clear source-of-truth versus derived-index responsibilities. - Defined concurrency and idempotency behavior rather than happy-path CRUD alone. - A simple initial architecture with justified seams for later scaling. ### Follow-up Questions - How would collaborative playlist editing change the consistency model? - How would you rebuild the search index without losing updates? - How would playback commands behave if two devices control the same session?