Design a Karaoke Duet Feature

Problem statement

Design a karaoke duet feature that lets two remote users perform the same song and produces one merged performance. The product supports two families of experience: an asynchronous mode where singer B records over singer A's committed recording (or both record against the same backing track and the platform merges later), and a live mode where both are online at once. The platform must create and pair sessions, distribute the licensed backing track, capture each vocal stem, align the stems in time, mix them with balanced loudness, score the result, and publish it to a shared feed, scoreboard, or social channels.

The defining constraint is physics, not databases. Two singers in different cities cannot hear each other with the 20-30 ms ensemble tolerance that human musicians need: inter-city round-trip latency is typically 60-150 ms, and no codec, buffer, or cloud region removes that distance. Therefore the design must separate three things that naive answers conflate: (1) session coordination, which is an ordinary distributed workflow; (2) live co-presence, which is a realtime media problem solvable with an SFU for monitoring and a synchronized backing-track playout clock; and (3) the merged performance itself, which is an offline alignment-and-mixing job over locally recorded stems. Smule built the largest remote-duet catalog in the world on exactly this split: record locally against a shared reference, align server-side, merge after the fact.

Why the problem is distinctive

A photo-collage feature can tolerate arbitrary ordering; audio cannot. A 60 ms misalignment between two vocal stems is audible as an echo; 200 ms is a train wreck. Clock drift between two phone audio hardware clocks adds tens of milliseconds per song if uncorrected. Device input and output latency varies by handset, OS, Bluetooth path, and buffer size, so the recorded offset is not a constant. These facts force specific architecture: a shared reference timeline (the backing track and its beat grid), per-device latency calibration, drift-aware resampling, and a server alignment engine with cross-correlation refinement.

Public operating baseline versus design assumptions

Public evidence shows the category is real. Smule's Sing! app popularized remote duets, including celebrity duets, on a catalog used by tens of millions of users (company-reported). StarMaker reports tens of millions of monthly active users with live karaoke rooms and duet battles (company-reported). TikTok's Duet feature demonstrates async two-performer content at billion-user scale. These are context signals, not our design targets.

For capacity planning this answer explicitly assumes a mature product with 8 million MAU, 1.2 million DAU, 350,000 duet sessions per day, 60,000 concurrent live-room participants at peak, and a 5x event peak. Unless tied to a citation, every number here is a stated design assumption.

The four architectural planes

1. Session plane: invites, joins, mode selection, custody of the duet workflow, and durable state transitions.
2. Media-capture plane: backing-track distribution, local recording, device-latency calibration, and stem upload.
3. Render plane: alignment, drift correction, mixing, loudness normalization, scoring, and encoding.
4. Social plane: publishing, feed fanout, leaderboards, sharing, and moderation.

A strong interview answer keeps these planes separate: the social plane may degrade without hurting capture, and the render plane may queue without losing any recorded stem.