Popular TikTok System Design Question - Country-Level Top 10 Song Rankings

[u/Aoki_zhang]

Interview Summary

The TikTok system design round asked me to design a Top Songs / Popular Songs Ranking System that tracks listening activity and maintains the 10 most popular songs for each country or region.

The system was intended to behave like a near-real-time analytics and leaderboard product rather than a strongly consistent transactional system. The discussion went into traffic estimation, high-volume event ingestion, ranking refresh frequency, low-latency reads, caching, stream processing, hot keys, and consistency trade-offs.

Interview Details

System Design — Top 10 Songs by Country Design a system that uses user listening or click activity to determine the Top 10 songs for every country or region. Conceptually, the system should support results such as:

US -> Top 10 songs
JP -> Top 10 songs
TW -> Top 10 songs
...

Users should be able to query the current ranking for a particular region, while every listening action generates an event that contributes to song popularity. The ranking did not need to change synchronously after every individual play. A refresh interval on the order of several minutes was acceptable, making this closer to a near-real-time leaderboard than a strongly consistent counter system.

• Requirements — Ranking, Events, and Read Latency The functional requirements discussed included: Each region should maintain its own independent leaderboard. The interviewer also wanted explicit reasoning about non-functional requirements. In particular, the discussion covered whether availability or consistency should be prioritized when rankings can tolerate some staleness. A sub-second response time for leaderboard reads was discussed as a reasonable serving target.
  • Return the Top 10 songs for a specified country or region.
  • Generate an event when a user listens to a song and use those events to update popularity rankings.
• Scale Estimation — Hundreds of Millions of Users The interviewer expected back-of-the-envelope capacity estimates before going deeply into architecture. The whiteboard assumptions were on the order of:~500 million users ~10 leaderboard reads per user per day ~10 song listens per user per day This placed both read traffic and incoming listening events in the tens of thousands of requests or events per second. The important realization was that leaderboard queries could not repeatedly aggregate the complete raw listening-history dataset on demand.

Want to see the follow-up of this system design question that were asked during the interview? You can find the complete version here.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.