One of the most critical sections of interviewing at a top company or senior role is the System Design section where you would have to come up with an efficient architecture for a system they would ask.
In this tutorial, I will talk about an efficient way to design Spotify’s real-time music player. Now keep in mind, a recruiter or hiring manager does not expect you to know how to actual code such a system. However, they do want to see if you have that knowledge to come up with a system for a billion users.
Let’s take a look at the design first.
When coming up with this design, we assumed a few things.
1. The users are already logged in
2. We have over a million users
3. The database is already designed
4. We are only focusing on what happens when a user plays a specific song
Alright then. Now let’s get familiar with all of these terms. As mentioned earlier, no one expects you to know the ins and outs of building such a system as there are a number of ways to do so. During a System Design interview, it is important to come up with a general design without being specific of what technologies you would use.
Load Balancer — a load balancer is used to maintain and handle traffic coming into a server. When a user requests for a specific page, instead of the request going to the server directly, it goes to the load balancer. The load balancer uses techniques such as Round Robin to distribute the request to the server with the least traffic. It allows us to scale up our infrastructure behind it to handle any throughput that it is seeing. This makes the user’s experience seamless. Large applications such as Spotify have a number of servers to manage all of it’s users. The best way to maintain these is by using a load balancer. Load Balancer can be configured on NGINX.
Publish/Subscribe — The next part of this design is the publish/subscribe or pub/sub pattern in short. The reason we used pub/sub is because users would be clicking “play” every milliseconds. It is not efficient to process data to and from a database that quick. As a result we use a message queuing system such as a pub/sub model to stack up all these requests and then process them. RabbitMQ and Apache Kafka are two popular pub/sub.
In other words, pub/subs are temporary memories that hold requests for a limited amount of time.
App Server Producer /App Server Consumer — Producers are those client applications that publish (write) events to the pub/sub, and consumers are those that subscribe to (read and process) these events. In a pub/sub system, producers and consumers are fully decoupled and agnostic of each other, which is a key design element to achieve the high scalability.
Data Warehouse — Up to a point databases are useful. However when you have millions and millions of data, we need something stronger, scalable and efficient to handle all these queries. A data warehouse does just that. It distributes all the tasks across a number of machines and does parallel processing. An example of such a system would be Hadoop Distributed File System.
Hopefully now we are familiar with the sub parts of our architecture. Now let’s talk about what is happening in our design,
Users are clicking on “play” on their phone. The requests are getting stacked up and processed by the pub/sub in real time. Independently, two things happen next asynchronously.
1. The data is being updated directly from the pub/sub to the artist. That is, as soon as a user plays a song by an artist, the number of times that song has been played by users gets updated on the Artist’s dashboard. This allows real-time updates instead of updating and retrieving data from the data warehouse.
2. Simultaneously, the data warehouse is getting updated with the new information.
There. We have a part of the real-time system Spotify uses.
If you guys learnt something new, please drop a clap and follow me for more tutorials.
The tool I used for designing — https://app.diagrams.net/