Hello there and welcome to this system 
design mock interview. Today we want to show you a   really high-quality, best-in-class system design 
answer so that you can use it to prepare for   your interviews and use it to know exactly what 
standard you should be aiming for.

With us today,   giving us the answers, the candidate today, I have 
a former Engineering Manager at Google, it's Mark.

Mark, how are you doing? I'm doing great, Tom. Thanks 
for having me. I'm looking forward to doing this.   Oh, thanks for thanks for coming on. It's 
great to have you. Before we get started,   just want to quickly give people an idea of 
your background as an Engineering Manager.

Yeah, I was an Engineering Manager at Google for 
13 years and worked on several large-scale systems   with lots of great engineers.

And so I I hope 
I've learned a little bit from them and it'll   be interesting to see me on the other side of the 
fence of uh of uh doing the being the interview   candidate here, so I'm looking forward to it.

I'm 
sure you'll do a great job. Yeah, and Mark also is a   coach on our platform.

So if you need some expert 
feedback ahead of your interviewer Google, Facebook,   anywhere, any tech company, then do check him out 
on our platform. Okay, uh if you're ready Mark,   let's crack straight into it.

The question I want 
to ask you today is, how would you design Spotify? Okay, uh so yeah, so uh Spotify, probably one 
of the most popular music streaming services   out there, I guess.

Uh so let's let me let me 
think about that just for a moment.   Um because there's lots there's a lot of aspects 
of Spotify here. Let me see if I can actually maybe   I'll just take some notes here so that I can kind 
of I think I think through this if that's okay.

And   and can I get some uh make some assumptions.

So 
I have my notes. I'll just put this right in here.   And then if it's okay, I'll just use this for 
notes as well as sort of the design diagrams   and things like that later on.

Yeah, sounds good. 
So yeah, so let's yeah, so let's talk about just   some different sort of Spotify. Okay, so I for 
Spotify, I can I can think of things, I mean,   obviously there are songs, music, that's the main thing.

Uh, there's, you know, you have playlists. I mean, there are users, there are artists. Uh, I guess Spotify even has things like podcasts, that you know you can listen to and things like that.

So there's a lot to it. And so in terms of the system design for today, uh, is there, is there like, can we, can we constrain this a little bit just so that we can actually get through a design?

What would you, what would we, would be good to focus on here?

Yeah, let's constrain it. Let's limit ourselves to let's look at finding and playing music. Okay, okay. So let me, uh, so use cases, finding, uh, and playing music. I'm just going to write it down like verbatim here.

Great. Yeah, I think enough to talk about. I think so. Yeah. Okay, good. So, uh, if I, if I think about that, let me, let me try and ask a little bit or think a little bit about the use cases a little bit more.

So my typical use case then as a user if I'm signed up to Spotify, and I have an app on a phone, uh, I am going to browse some music, maybe I'll find a particular, search for a particular song, but, but then the most core thing is that I play a song and it's you know, coming back through my phone, maybe my car or whatever, wherever I might be, headphones, uh, to listen to it with.

Big broad questions like this, you need to constrain the problem, make it solvable in the space of an hour and Mark did this well, establishing the use cases we wanted to focus on.

If you're asked to design an already existing system, in this case Spotify, share what you know about it with the interviewer.

They can correct you or fill you in if you have any knowledge gaps. So if I think about other, if I think about metrics here, let's think about size.

Let's, let's do some quick, quick drilling down into, into some numbers here. And pardon me while I get this going here. So in numbers, so tell me about how many users you're thinking about here for, for this design?

Yeah, let's say a billion users. Okay, one billion users. Okay. What about number of songs? Yeah, I think I saw, I think I saw it somewhere that Spotify has about 80 million songs, but let's say we need to have capacity for 100 million on there, okay?

All right, so 100 million songs, a billion users, and you know, we're we're going to focus on the song piece of it.

So, but let me do a little bit of uh of math here, or a little bit of thinking, and you can I can I'll just, you know, double check with you to make sure that this makes sense.

But from what I know, think about a typical MP3 audio is going to be about for a typical song, is is about five megabytes.

And I mean, I think that depends on the encoding of the song, how long the song is, and things like that. But uh if that if that if that's okay, we can just kind of make that assumption.

Is that fair? Yeah, that sounds good to me. Yeah, I mean, I think you can encode these things in, you know, really low quality, like 96 kilobits per second, all the way up to 320 kilobits.

But right in the middle, 128 to 160 is about maybe about that. So, all right, so let's assume that.

And so then let's do, let me just extrapolate from this. So if you've got five megabytes per song, you've got 100 million songs.

So I think, uh, that translates to, I'm trying to do my math here. So, 100 million would be uh going to a thousand times that would be 100 billion, and then 100 trillion would be a million times times five would be 500 trillion.

So we're talking about uh total audio is something like 500 terabytes, which is I guess it's the same thing is half a petabyte of data.

And so that's I'm making that assumption. And so then depending on how you replicate this data, because you typically want to have these songs in multiple, you know, have multiple copies of these things so they don't get lost, et cetera, and if some replica is down.

So, you know, maybe you do, let's say oops, sorry, my keyboard here, 3x replication, so that would mean like one and a half petabytes of of raw audio data.

And then, and then each song in terms of the metadata, meaning the, you know, the, the song title and things like that, and and artists and all these things, the metadata is probably not very big.

It might be, I don't know, you know, 100 bytes per song or something like that per song of metadata.

And so you might wind up with, okay, so let me do the, you have it and that's a, a billion, 10 billion, so that's only 10 gigabytes of of song metadata.

And even if you say it's, it's a kilobyte, then that's 100 gigabytes, so it's not very much. And let me just double check my math here.

100 million times 100, really 100 bytes? Yeah, I think that would be 10 gigabytes. So even if we said, if we rounded it up dramatically and said 100 gigabytes, that's just not a ton of data.

Now, in terms of users, uh, user data, you might have, you know, again, like a, maybe you have a kilobyte, oops, kilobyte per user metadata. I guess it's all metadata.

And so, uh, that might be times a billion users, so that would be a terabyte of data approximately.

So just to kind of, so this is just me doing some quick metrics, quick calculations to get a rough back of the envelope of how big these things are.

Uh, so does that make sense so far? Does that seem, yeah, that will make sense so far. Before starting your high-level design, as Mark did, get some metrics to help you identify any higher- level decisions that might be influenced by the scale of the system.

Mark asked the right questions about the number of users and number of songs. I made some rough calculations without getting bogged down in the numbers.

What Mark didn't calculate was the traffic, how many songs are streamed per day or per second even. That would have helped him figure out the scaling of the web servers, how many he'd need, and how much bandwidth he'd need.

However, since this didn't impact his high-level design, it was okay not to go into the details of scaling at this point.

Okay, so let me let me maybe think about some basic components here. And I'm going to draw them, but I I'll get into them maybe a little bit more in detail later.

Okay, so some basic components that I would see. So let me let me start with something that is my my best attempt at a mobile phone here. So you've got your Spotify app. I'll make this smaller so it fits into the thing.

So you've got your app, which is on your phone typically. And I'm going to assume here that we're talking about the phone app because that's very common. Uh, and so you've got your your phone.

The phone is going to be talking to uh an application server, a Spotify application server somewhere, or web server, I guess. And so let's draw some, let me just put a like over here, just say there's a Spotify web server.

Uh, and uh, and there's not going to just be one, there's going to be lots of them. And assume that that's a lot.

And then of course, just because this is a standard thing that you do when you have applications uh, you know, in the cloud here, this is I guess part of the cloud, you've got a load balancer. And so let me draw.

Let's assume that we've got an arrow here that's talking, so Spotify app's talking through the load balancer ultimately to these to these web servers. And so those are the those are some some sort of key components here.

Let me think about this a little bit further. Yeah, I think that's good so far. Okay. And then of course, the most important thing, or one of the most important things here.

Let me see if I can find a, I know that there's a shape here. Here we go. That's a that's a good shape.

I'm just going to say call this uh the database. And let me make this a little bit more uh, let's see, that's what I wanted. Okay, so there's a database. And so the web servers are going to be talking to the database and getting stuff from, basically reading information, writing information to and from the data, reading and writing information to and from the database.

So those are kind of the very high-level components. In system design interviews, good dual bandwidth communication is important. That's to say, you need to communicate well via both drawing and speaking.

You should practice this thoroughly before your interview. Mark did this well. He started drawing the components quite early on in his answer, and this allowed the interviewer to follow along easily.

It's okay to have simpler and fewer components at this point in the interview. You can then break it out later in your answer, as Mark did when he splits his database in two and I probably am thinking about this, I think this is obviously oversimplified and I'm not going to redesign Spotify, uh, you know, the existing full application as it exists, but I do think I can get a little bit more detailed here by I think I'm thinking about the data again because it's it's the data is important.

So I'm thinking about the metadata and the user data and the audio data.

and they're different, very different types of data. So I'm going to actually, I'm going to split this database here into two things, and I'll explain that, or I'll try to explain them just a little bit.

Come on, there we go. Make this just a little bit more uh, so I'm going to split this up and say that I'm going to there's a like a song audio database and then there's going to be like a metadata database.

So this is users, uh, songs, uh, what else?

I mean, there ultimately there probably be artists and etcetera, things like that, but we're focusing on the songs, I think, in the in the music and so on. This is also a database, of course, song audio database and metadata.

And so I think, let me make this a little bit more, uh, this Spotify web server is actually going to talk to this to the meta, oops, the metadata and uh, and the audio database.

It's actually going to be talking to two databases here. Yeah, that's interesting. Can you can you can you go into a bit more detail about why you'd split them into two?

Yeah, yeah, I'm kind of making that uh just assuming that or making that, yeah. So, okay, let me, let me try and, I wanted, I want to answer. Let me try and think of this in terms of the technologies that I might use.

I might use something like Amazon S3 here and I might use Amazon RDS. And so now let me explain what I mean by that. So, the type of data that the actual MP3 files, those I think of as immutable data.

They're just blobs of data, they're files, they're five megabyte roughly on, you know, on average files, and they're not going to change.

They're just being streamed, they're being, you know, stored and streamed essentially.

And so a blob database, which is what S3 is, lends itself really well towards that. And it could be something like Google Drive, or there's other, you know, technologies that are sort of just document-like blob storage uh systems.

But Amazon S3 lends itself really well to that, and it scales uh greatly. You can just add more and more and more and more, and it scales uh linearly, which is great.

And and so and then you can connect it up to to be able to stream the data and things like that. So, that type of data and the access patterns for that, which is really mostly read, you're just streaming this data.

You're never going back and forth and writing to it. That would be why I would want to put the songs in that kind of a database.

Now, S3 is great for that, works really well. But the data, the metadata, which is the the users and their information, and the songs and their information, and uh maybe they get updated, maybe you're searching across them and having to do queries to find songs for a particular genre or artists or things like that.

Or you're trying to update your users, like if I'm playing a playing a song and I want to remember where I left off so that when I continue playing it, it remembers that.

I'm going to be modifying the data quite a bit or going back and forth between that database and doing these queries.

And you can't really do queries over S3, but you can over like a relational database. So MySQL would be another option. Uh, I just chose RDS here, really Amazon's relational database as a, as a because I'm going with the AWS family here.

But yeah, so uh, let me, let me try and try and just write something here a little bit more in terms of in terms of songs, you would have things like a song ID, you would have a song, maybe, maybe a URL like that you'd use for sharing.

Uh, you would have an artist, a genre, maybe there's a link to album cover and maybe there's the link to the, to the audio, I guess.

So this is too, too big to fit. So this is the type of data that would be stored in uh, let me draw this in here again, like in that, in that database.

And then just the raw, I mean, I almost don't need to write this here. So song MP3 would be stored in this database down here.

So yeah, so I think that the access patterns, the types of things that you want to do, the size of the data, because the size of the data here, I think we said was going to be, well, half a petabyte in one, in one for one replica.

The data here is going to be, you know, in the, you know, maybe terabyte range, uh, something like that. And and it's going to have lots of queries over it, maybe some updates and things like that.

So that's why I would separate these out is because I think the access patterns, the size of the data and the type of, uh, the type of queries that you need to be able to do over would be very different.

Does that make sense? Yes. Does that answer? Yeah, yeah, it does. Thank you. Yeah, I think that makes sense. At this point of your answer, when you've laid out the main components, it's good to start identifying some technologies, as Mark did here, starting with the database.

His design made sense, breaking up the databases into audio data and metadata, but he could have explained why he was doing this upfront, rather than waiting for the interviewer to ask why.

In general, try to be upfront about your decision making. Yeah, feel free to, feel free to continue.

So, okay, so let's say we have these two databases and I'm just trying to think about now the actual, the two, the use case, sorry, the use cases we talked about, so finding and playing music.

So, for finding music, I think the Spotify app, you know, would need to request to do a find music. And so the user probably, you know, either is typing in like an artist's name or maybe they're selecting a bunch of filters.

I actually am not that familiar with how possible that is, but let's say I'm searching for music for an artist with a particular genre.

And so ultimately, somehow I'm filling in this query in my app, either by clicking on some things or typing some things or a combination. And then that request to find music is going to be sent to this web server, going through the load balancer to pick up a web server.

It's going to go there, and then that web server is going to do a query, issue a query, a translated query to the relational database to find a bunch of songs and return a list of songs, and return that back up to the app with whatever metadata there is.

And let's say that I found it finds, I don't know, 100 songs that match my request for Korean pop music or something like that.

And so I now get back 100 songs, and I can look at those.

And now once I've gotten that list of songs, and by the way, for that query where I'm searching for music, I don't touch the MP3s at all.

I don't need to go to that database at all. I just need to go to the metadata database and do this query.

And because it's a relational database, that query can happen pretty efficiently, etc. So now I return that information back, and then I display that to the user.

Google system design interview: Design Spotify (with ex-Google EM)

High quality, best-in-class mock interviews for candidates at tech companies (software engineers, engineering managers, MLEs, data engineers, etc)

Watch superb system design interview answers from senior engineers who worked at Google, Meta, and Amazon.

We've added insightful feedback at points throughout the video to help you with your system design preparation.



Google system design interview: Design Spotify (with ex-Google EM)

Google system design interview: Design Spotify (with ex-Google EM)

Scripts