Design a Collaborative Playlist Editor
Company: Databricks
Role: Frontend Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
## Design a Collaborative Playlist Editor
Design the data model and APIs for a playlist application. Authorized collaborators can add a song, remove a playlist item, or move an item to a new position. When one user changes a playlist, other active collaborators should receive enough information to update their views.
Focus on data modeling, API behavior, ordering, and collaboration events. Large-scale distributed infrastructure is out of scope.
### Constraints & Assumptions
- A playlist may contain the same song more than once; each occurrence needs its own stable item ID.
- A playlist contains up to `100,000` items and may receive concurrent edits.
- Reads should return one deterministic order.
- Mutations must either complete fully or leave the prior playlist unchanged.
- Clients may reconnect and retry requests or event delivery.
### Clarifying Questions to Ask
- Who can view versus edit a playlist?
- Does moving an item target an absolute index or neighboring item IDs?
- Must concurrent edits be merged automatically, or may one fail with a version conflict?
- Are collaboration updates delivered by webhook, WebSocket, or either mechanism?
- How should disconnected clients catch up on missed changes?
### Hints
- Model a playlist occurrence separately from the song catalog record.
- Compare contiguous position numbers, rank tokens, and explicit previous/next links.
- Give every mutation and emitted event a stable identity and playlist version.
### What a Strong Answer Covers
- Playlist, item, membership, and song entities with keys and ordering fields.
- Concrete add, remove, move, list, and subscription/event contracts.
- Ordering tradeoffs and the write/read cost of the chosen representation.
- Atomic mutation plus reliable event publication.
- Concurrency, idempotent retries, version conflicts, and reconnect recovery.
### Follow-up Questions
- How do you move one item without rewriting thousands of rows?
- What happens when two users move the same item concurrently?
- Which event payload would each mutation emit?
- How can a client detect that it missed one or more events?
- When would linked-list ordering be preferable to fractional rank tokens?
Quick Answer: Design the data model and APIs for a collaborative playlist where stable item IDs allow duplicate songs, removals, moves, and concurrent edits. Explain deterministic ordering, atomic mutations, idempotent retries, version conflicts, reliable events, and reconnect recovery without requiring large-scale infrastructure.