Design Top K Songs Service

Microsoft's "Design Top K Songs Service" interview question focuses on building a scalable system to track and serve the top K most-played songs, often in real-time or over specific time windows, incorporating data engineering pipelines, caching, backend services, web APIs, machine learning for ranking, and stream processing.[1]

Problem Statement

Design a service that processes song play events (e.g., from a music streaming app like Spotify) and efficiently returns the top K songs by play count. Start with all-time top K under low traffic, then scale to high QPS (e.g., 1M requests/day), handle 10B plays/day across 100M songs, and support time-based windows like last 24 hours or sliding windows of X minutes using tumbling or sliding windows. K is typically 100-1000. Use stream processors (e.g., Kafka Streams, Flink), caching (e.g., Redis), and sharding for scalability.[2][1]

Functional Requirements

• Record song plays in real-time via event streams.
• API to query top K songs: GET /topk?k=10&window=24h®ion=us.
• Support global all-time top K, then time-windowed (e.g., last X minutes/hours).
• High throughput ingestion (10B events/day) with low-latency queries (<100ms).
• Scale horizontally with load balancing, replication, and partitioning.[3][1]

Non-Functional Requirements

• Scale: 10B song plays/day, 100M songs, 1M API calls/day.
• Latency: Queries in 100ms; ingestion resilient with queues.
• Availability: Replicate caches/DBs, use TTL for freshness.
• Consistency: Eventual for counts; accurate top K via aggregators.
• Cost: Efficient storage (e.g., no full scan of 100M songs).[1][2]

Input/Output Examples

No formal I/O formats in sources, but typical API examples include:

Request: GET /api/topk?k=10&window=24h

Response: [ {"song_id": "song1", "title": "Hit Song A", "plays": 120000}, {"song_id": "song2", "title": "Hit Song B", "plays": 115000}, ... ] Plays aggregated over window; sorted descending.[2][3]

Constraints

• Event volume: 10B/day (~115k/sec peak).
• Catalog: 100M unique songs.
• K: 100-1000 (small result set).
• No full scans; use heaps/Count-Min Sketch for approx. top K in streams.
• Windows: Tumbling (e.g., 24h) or sliding; refresh every 1-60min.
• Storage: Metadata ~1TB; raw events to data warehouse for batch correction.[9][1]