Databricks interview report · Spotify API semantics · Engineering synthesis

Collaborative Music Playlist

Create, view, update, share, and reorder playlist entries while multiple clients receive one durable, convergent sequence of changes.

Core operationsCreate, view, update
Ordered listAdd, remove, move
EditorsOwner + collaborators
Consistency unitOne playlist

Problem statement

Design a Spotify-like music playlist application. Users manage playlists, view their contents, update metadata and membership, and reorder items. The collaborative extension allows several authorized users to add, remove, and move entries concurrently.

Minimal API

POST /playlists { title, visibility } → playlist, versionGET /playlists/{id}?cursor=... → entries, versionPOST /playlists/{id}/mutations { op_id, base_version, operation }GET /playlists/{id}/events?after_version=...

Relational source of truth

  • playlist(id, owner_id, title, visibility, collaborative, version)
  • playlist_entry(id, playlist_id, media_id, position_key, added_by, added_at)
  • playlist_member(playlist_id, user_id, role)
  • mutation(op_id, playlist_id, version, actor_id, type, payload, created_at)
  • outbox(event_id, playlist_id, version, payload, published_at)

Store all rows for one playlist on the same SQL shard. One transaction updates the ordered list, advances its version, records deduplication state, and creates the event for live delivery.

Component model

  • Playlist API: stateless reads, validation, and routing.
  • Owner partition: one mutation order per playlist.
  • SQL primary: durable membership, sequence, version, and outbox.
  • Redis: derived snapshots for popular reads.
  • Kafka + fanout: committed events to WebSocket gateways and projectors.
  • Catalog service: track metadata and availability by media ID.

See the complete architecture and interactions →

Design center

Occurrence identityEach playlist occurrence owns a stable entry ID because one track can appear several times.
Per-playlist orderRoute mutations for one playlist through one logical owner that assigns monotonically increasing versions.
Optimistic clientsApply local intent immediately, then reconcile from the server acknowledgement and canonical broadcast.
Versioned writesEvery accepted add, remove, or move creates a new playlist version, matching Spotify snapshot semantics.
Durable plus ephemeralPlaylist mutations enter the durable log. Presence and drag previews use expiring state.
Requirement-driven P2PUse the P2P branch when offline editing, device-held state, or service-outage operation becomes a core requirement.

Recall test

  1. Why does an entry need an identity distinct from its track?
  2. Which component assigns playlist versions?
  3. Why is SQL the canonical store?
  4. Which records commit with a mutation?
  5. Why does Kafka receive events through an outbox?
  6. How does an offline client catch up?
  7. Which collaboration state can expire?