Song Recommendation System

Amazon's "Song Recommendation System" interview question appears to be a system design problem focused on backend scalability, recommendation algorithms, web serving, and machine learning integration. No single source provides an exact match with all specified tags and a "full" problem statement including input/output examples or constraints, but aggregated details from common interview prep resources point to a standard formulation.[1][2]

Problem Statement

Design a song recommendation service like those used by Spotify or Amazon Music. The system should generate personalized top-10 song lists for users based on listening history, preferences, and behavior. It must handle high-scale traffic (e.g., 10M+ users, 100K+ QPS at peak), deliver recommendations in under 200ms latency, and support real-time updates from user interactions like plays, skips, and likes. Key challenges include personalization via ML models (collaborative filtering, content-based), candidate generation, ranking, and graceful degradation.[2][3]

Functional Requirements

• Generate/update user-specific top-10 song recommendations on-demand or periodically.
• Support new user cold-start (e.g., via popular songs or demographics).
• Incorporate real-time feedback (e.g., update recs after a song play).
• Filter out inappropriate content and recently played songs.
• Provide diverse recommendations (avoid over-recommending the same artist/genre).[7][2]

Non-Functional Requirements

• Scale: 10M+ users, 100K+ QPS, 99.9% availability.
• Latency: <200ms p99 for recommendation fetches.
• Storage: Billions of songs/users with metadata (artist, genre, lyrics embeddings).
• Cost: Optimize for offline batch processing where possible.[1][2]

Input/Output Examples

No explicit code-style I/O formats are detailed in sources, as this is a system design question rather than a coding one. Typical API examples include:

Input (API Request): GET /recommendations?user_id=12345&count=10&session_id=abc&recent_songs=[song1,song2]

Output (JSON Response): { "user_id": "12345", "recommendations": [ {"song_id": "456", "title": "Song A", "artist": "Artist X", "score": 0.95}, {"song_id": "789", "title": "Song B", "artist": "Artist Y", "score": 0.92} ], "timestamp": "2026-02-02T04:33:00Z" } Derived from standard recsys designs; real-time inputs may include context like device type or location.[2][7]

Constraints

• Data volume: 100M+ users, 1B+ songs, TBs of interaction logs (plays, ratings).
• No single points of failure; use sharding (e.g., by user_id).
• ML models: Train offline on Spark/Airflow, serve online via TensorFlow Serving or SageMaker.
• Edge cases: Offline users, zero-history users, high-velocity events (concerts trending).
• Trade-offs: Precompute for speed vs. real-time for freshness.[3][5][1]