Top-K charts system design

Questions to ask the interviewer

The design in short

A chart looks like a simple list, but it sits on top of a counter that never stops. Every play adds to one song, and every chart view wants the top 10 and the rank of one song right now. The interview is about keeping both of those cheap at the same time.

Counting is easy, ranking is not. Adding to a counter is one small write. Finding where a song stands means knowing how many songs sit above it. If each view sorts or counts the whole catalogue, the cost grows with the number of songs, and a music app has millions. Ask what shape the data should keep, so a rank is a quick lookup and not a scan.

Writes and reads pull in different ways. Plays arrive as a steady stream and must all count. Views want a fast answer and can live with a chart that is a little behind. The brief gives you that room: a play must show within a minute, not at once. Think about which side waits for which, and where the counts are kept between them.

Parts to sketch before you commit:

• the servers that take plays and the servers that answer chart views
• the store that holds each song's count, and whether it can give an order as well
• how a play travels from the app to that store
• what a chart view reads, and how many reads it needs

Do the arithmetic per view. Take the views a second and multiply by the work one view does. Then do the same for plays. A design that asks a database for a long list on every view will show its limit here, before any traffic arrives.

Keep the scope narrow. A leaderboard in a game is the same problem with players and scores, so the same reasoning carries over. Charts per country or per genre are fair follow-ups, but leave them for later.

Send the plays through your design in GonnaCrash and see which part runs out of room first.