Design Music Discovery

Problem Statement & Context

Build the discovery plane of a music streaming product: personalized home rows, algorithmic playlists (Discover Weekly, Release Radar), artist radio, and search-aware recommendations driven by listening patterns — not the full playback/CDN stack (assume a sibling playback service exists).

Interviewers probe event pipelines, retrieval + ranking, cold start, exploration, and rights-aware filtering at Spotify/Pandora/Apple scale.

Scale anchors: 400M+ MAU, billions of play/skip events daily, 100M+ track catalog, home feed served hundreds of millions of times per day.

Extended interview notes

Problem Statement & Context note 1: Tie problem to measurable discovery SLIs: home-feed p95 <120ms, playlist freshness <24h, skip-rate uplift vs editorial baseline.
Problem Statement & Context note 2: Separate online ranking path (milliseconds) from offline batch jobs (Discover Weekly) with explicit idempotency keys.
Problem Statement & Context note 3: Rights-filter candidates before scoring — unlicensed tracks never enter the ranker to avoid legal incidents.
Problem Statement & Context note 4: Use two-tower retrieval (user embedding · track embedding) then re-rank with contextual bandits for exploration.
Problem Statement & Context note 5: Cold-start users need popularity + audio-neighbor fallbacks; power users need diversity constraints (MMR).
Problem Statement & Context note 6: Event bus carries play_start, play_30s, skip, save, follow — each with schema version for safe consumers.
Problem Statement & Context note 7: Feature store serves point-in-time correct vectors; training must not leak future plays into past snapshots.
Problem Statement & Context note 8: ANN index (HNSW/FAISS) sharded by region; rebuild jobs are blue/green to avoid serving half-old graphs.
Problem Statement & Context note 9: Cache per-user home rows in Redis with TTL + version stamp; bust cache on taste-profile updates.
Problem Statement & Context note 10: A/B infra assigns experiment buckets at login; metrics: listen-time, saves, skips, day-7 retention.
Problem Statement & Context note 11: Radio mode needs sequential re-rank with session context — not the same scorer as static playlists.
Problem Statement & Context note 12: Editorial slots (10–20%) guarantee label commitments and cultural moments without drowning ML.
Problem Statement & Context note 13: Observability: candidate_recall@k, scorer_latency_p99, feature_staleness_seconds, index_lag_minutes.
Problem Statement & Context note 14: Failure: stale features → degrade to editorial; ANN outage → popularity fallback; never empty home.
Problem Statement & Context note 15: Cost driver is embedding inference + ANN RAM; batch training is amortized weekly, online is hourly.
Problem Statement & Context note 16: Privacy: aggregate taste profiles; minimize raw IP in features; honor delete-user cascades on vectors.
Problem Statement & Context note 17: Multi-region: replicate read-only indexes; write events to regional Kafka then mirror to global lake.
Problem Statement & Context note 18: Idempotent playlist materialization jobs keyed by (user_id, playlist_type, week_id).
Problem Statement & Context note 19: Explain trade-offs aloud: batch freshness vs online reactivity; exploration vs exploitation.
Problem Statement & Context note 20: Close with how you validate ranking quality offline (NDCG) before shipping experiments online.

Why interviewers care

Music Discovery interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement & Context that proves you understand real outages, not happy-path diagrams.

Key Highlights