# Design a Near-Real-Time Top Songs Service by Country Design a service that consumes song-listen events and serves the ten most popular songs for each country. Assume roughly 500 million users, about ten leaderboard reads and ten listens per user per day, which puts both paths near 50,000 requests per second. Rankings may refresh every ten minutes, responses should normally take less than one second, and availability is more important than immediate consistency. ### Constraints & Assumptions - Each listen event has a song identifier, event time, user or event identifier, and a trusted country assignment. - A listen must not be counted twice when producers retry. - Raw event volume is too large for a grouped database query on every read. - A song can become globally popular and create hot partitions. - Historical events must remain available for correction, audit, and replay. - For one reproducible illustration, rank eligible songs by listen count descending, then by canonical song ID in ascending bytewise order; publish the first ten, or all songs when fewer than ten qualify. This cutoff policy is a design choice, not a preserved source fact. ### Clarifying Questions to Ask - Is popularity all-time, over a sliding window, or within calendar periods? - Which events qualify as a listen, and how are bots or fraudulent plays handled? - How late may events arrive, and how accurate must a ten-minute ranking be? - How many countries and songs are active, and is personalized filtering required? - How should equal counts be ordered, and should a tie at rank ten be broken or include every tied song? ### What a Strong Answer Covers - Capacity estimates and explicit freshness, latency, durability, and consistency targets - An asynchronous ingestion path with durable partitioned events and idempotent processing - Incremental per-country, per-song aggregation and bounded top-k computation - A small materialized leaderboard cache for the low-latency read path - One versioned, deterministic tie and cutoff policy used by aggregation and serving - Hot-key mitigation, late-event handling, replay, failure recovery, and observability ### Follow-up Questions 1. How would you compute a rolling 24-hour ranking rather than an all-time count? 2. What partitioning scheme avoids one viral song overwhelming a worker? 3. How would you publish a corrected ranking after discovering fraudulent listens? ```hint Separate computation from serving Treat listen ingestion, incremental aggregation, leaderboard publication, and read serving as distinct stages with different scaling and consistency needs. ```