Katkat
Back

Design a Collaborative Playlist Editor

DatabricksFrontend Engineer · Onsite
MediumFrontend EngineerOnsiteSystem Design

Last updated

Tests your ability to architect a real-time collaborative frontend application, focusing on client-side state synchronization, deterministic list ordering, idempotent mutation protocols, and graceful network reconnection.

Scenario

Design the client-side architecture, data model, and communication protocols for a real-time collaborative playlist editor (similar to a live collaborative session in Spotify or Apple Music). Multiple users can view, append, remove, and reorder tracks concurrently.

Requirements

Functional Requirements

  • Duplicate Tracks: The same song can appear multiple times in the playlist at different positions.
  • Mutations: Users can append tracks, delete any track occurrence, and reorder tracks via drag-and-drop.
  • Real-time Sync: Changes made by one user should reflect on other active users' screens in near real-time.
  • Optimistic UI: Local user actions (e.g., dragging a song) must render immediately without waiting for server acknowledgment.

Non-Functional & Technical Requirements

  • Deterministic Ordering: All connected clients must converge on the exact same playlist order, even under concurrent edits.
  • Atomic & Idempotent Mutations: Network retries or out-of-order deliveries must not duplicate or corrupt items.
  • Disconnection & Recovery: Clients that temporarily lose network connectivity must be able to catch up on missed events and reconcile local uncommitted state upon reconnecting.

What Your Design Should Cover

  1. Data Model: Distinguish between catalog tracks and playlist entries. Define the entry schema (including stable unique identifiers, track references, and position metadata).
  2. Ordering Strategy: Choose and justify an ordering scheme (e.g., fractional indexing, LexoRank, or CRDT-based sequence) that handles arbitrary insertions and concurrent moves efficiently without re-indexing the entire list on every operation.
  3. Client-Server Protocol & APIs: Define the WebSocket or HTTP event payloads for mutations (e.g., INSERT, MOVE, DELETE), including idempotency keys, client mutation IDs, and base revision numbers.
  4. Client State Management & Conflict Resolution: Detail how the client handles optimistic updates, pending queues, server acknowledgments, and rollbacks on failure.
  5. Reconnection & Catch-up Protocol: How a client resynchronizes state after being offline for seconds to minutes without transferring the entire playlist snapshot unnecessarily.

Hints

Hint 1

Differentiate the underlying media identity (e.g., `trackId`) from the playlist item identity (e.g., `playlistItemId`) to naturally support duplicate tracks with independent positions.

Hint 2

Fractional indexing or string-based rank keys (like LexoRank) allow moving and inserting items between adjacent neighbors using only a single item's update, but require a strategy for key collisions and floating-point precision limits.

Hint 3

Model client state as a combination of a confirmed server baseline and an unconfirmed optimistic mutation queue, reapplying pending local mutations over newly received server events.

Follow-up questions

  • How does your ordering approach handle two clients inserting an item at the exact same boundary at the exact same time (precision collision)?
  • If a user drags an item across 20 positions continuously, how do you prevent flooding the network while keeping the remote peers' views responsive?
  • How would you detect and resolve the situation where User A moves an item that User B deleted while User A was offline?