## Design a Music Playlist Service Design a service where users create playlists, add or remove tracks, reorder items, and retrieve a playlist in playback order. Focus on the service contract, storage model, concurrent edits, and reliable reads rather than frontend implementation. ### Constraints & Assumptions - A playlist has a stable ID and owner; authorization for shared editing must be clarified. - The same track may appear more than once in one playlist, so playlist-item identity is distinct from track identity. - Every mutation is retryable and must not duplicate an item after an ambiguous client timeout. - Ordering must remain deterministic under inserts, moves, and concurrent edits. - Required catalog size, playlist size, traffic, collaboration semantics, and freshness must be measured rather than assumed. ### Clarifying Questions to Ask - Are playlists private, public, or collaboratively editable? - What is the maximum playlist size, and how frequently are items reordered? - Must clients read their own edits immediately? - Are track metadata and availability owned by this service or by a separate catalog? - Is playback history, recommendation, or real-time co-editing in scope? ### Part 1 — Define APIs and the Data Model Specify operations for creating a playlist, reading it, adding and removing an item, and moving an item. Define playlist, item, track reference, permissions, and version fields. #### What This Part Should Cover - Stable playlist-item IDs even for repeated tracks. - Idempotency keys for creation and insertion. - Conditional mutations using a playlist or item version. - A read response with deterministic order and continuation behavior for large playlists. ```hint Model an occurrence, not just a track Two copies of one track need separate identities if a user can move or remove only one occurrence. ``` ### Part 2 — Maintain Ordering Under Edits Choose an ordering representation and explain the cost of inserting between items, moving an item, deleting an item, and occasionally repairing or compacting order keys. #### What This Part Should Cover - Why rewriting every later numeric position can become expensive. - Fractional or sparse order keys, linked relationships, or another explicit strategy. - Conflict behavior when two clients edit from the same version. - A safe rebalance path that does not expose mixed ordering states. ```hint Separate logical order from array position An order key can leave space between neighbors so most inserts do not renumber the entire suffix. ``` ### Part 3 — Serve, Scale, and Recover Describe the authoritative write path, caches or read replicas, event publication, hot playlists, deletion, observability, and repair of derived state. #### What This Part Should Cover - One authoritative mutation transaction plus a durable outbox or change stream. - Cache keys and invalidation tied to playlist versions. - Protection against one very large or popular playlist becoming a hot key. - Reconciliation, audit history, and metrics for conflicts, lag, and stale reads. ```hint Version every derived view A cache or search projection should reveal which authoritative playlist version it represents. ``` ### What a Strong Answer Covers - A clear playlist and item contract with authorization and idempotency. - Efficient, deterministic ordering and explicit concurrent-edit behavior. - A durable authoritative model with repairable read projections. - Scaling choices driven by playlist size, write skew, read traffic, and consistency requirements. ### Follow-up Questions 1. How would you support two users editing the same playlist in real time? 2. What happens when a track becomes unavailable after it was added? 3. How would you clone a million-item playlist without copying every row synchronously? 4. Which invariant would a reconciliation job verify after an ordering-key rebalance?