Spotify 디자인: 고품질 시스템 디자인 인터뷰

전 Google 엔지니어링 매니저 Mark가 음악 검색 및 재생을 위한 Spotify 설계에 대해 설명합니다. 시스템 구성 요소, 메트릭, 캐싱, 로드 밸런싱, 글로벌 복제 전략에 대해 설명합니다.

### Spotify 디자인하기: 고품질 시스템 디자인 모의 인터뷰
* 🎵  Google의 전직 엔지니어링 매니저인 Mark는 모의 면접에서 Spotify를 설계하기 위한 고품질 시스템 설계에 대한 답변을 제공합니다.
* 📱  그는 사용 사례를 논의하고 시스템의 사용자 수와 노래 수에 대한 지표를 수집하는 것부터 시작합니다.
* 🧠  그런 다음 Mark는 앱, 웹 서버, 데이터베이스를 포함한 시스템의 기본 구성 요소에 대해 설명하고 데이터베이스를 오디오와 메타데이터로 분리하기로 한 결정에 대해 설명합니다.
* 🌐  오디오 및 메타데이터 저장을 위한 기술 선택에 대해 자세히 알아보고 Amazon S3와 RDS에 대해 논의합니다.
* 📊  마크가 음악을 찾고 재생하는 사용 사례의 흐름을 살펴보고, 오디오 스트리밍과 캐싱을 위한 콘텐츠 전송 네트워크(CDN) 구현에 대해 설명합니다.
* ⚖️  마크는 로드 밸런싱에 대한 질문에 대해 다양한 메트릭의 사용과 스트리밍 데이터에 대한 더 스마트한 로드 밸런싱 체계에 대해 설명합니다.
* 🌍  그는 설계의 개선 사항으로 글로벌 규모 복제 및 지리적 인식 데이터 배치를 언급하며 마무리합니다.
* 👍  마크는 인터뷰에 대해 반성하고 피드백을 받고자 하는 의지를 표현하며 모의 면접을 긍정적으로 마무리합니다.

[Music] 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, they give 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 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 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, 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, so yeah, so Spotify, probably one 
of the most popular music streaming services out there, I guess. So let me think about that just for a moment. [Music] 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 think through this, if that's okay. And 
can I get some 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 talk about just some different sort of Spotify. Okay, so I for Spotify, I can think of things. I mean obviously there's songs, music, that's the main thing. Uh, there's you know, you have playlists. I mean there's users, there's 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, is there like 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 gonna 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 metrics here, let's think about size. Let's do some quick drilling down into some numbers here. And pardon me while I get this going here, so in numbers, tell me about how many users you're thinking about here for this design. Yeah, let's say a billion users. Okay, one billion users. What about number of songs? Yeah, 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 going to focus on the song piece of it. So let me do a little bit 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 about five megabytes. And I mean, I think that depends on oh, 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 [Music]. Yeah, I mean, I think you can encode these things, and you know, really low quality like 96 kilobits per second all the way up to 320 kilobits, but right in the middle 12860 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 a 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 Etc 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 song title and things like that, 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, uh, uh, billion, 10 billion. So that's only 10 gigabytes of song metadata. It's not really very much. 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 round it up dramatically and said 100 gigabytes, that's just not a ton of data. Now in terms of users, user data, you might have, you know, again like a maybe you have a kilobyte, oops, kilobyte per user metadata.

guess it's all metadata, and so, uh, that might be [Music] 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 marketed, 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 maybe think about 
some basic components here, and I'm going to draw them, but 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 start with something that is my best attempt at a mobile phone here. So you cut your 
Spotify app and 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. And so you've got your phone. The phone is going to be talking to 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.

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. 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 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. You know, the existing full application as 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 gonna 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, are ultimately there'll probably be artists and etc. 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 to 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 systems, but Amazon 
S3 lends itself really well to that. And it scales   greatly. You can just add more and more and more 
and more, and it scales linearly, which is great.   And so, and then you can connect it up 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 users and their 
information, and the songs and their information,   and 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, us 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.

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 so S3 lends itself well to that 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 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, uh, the Spotify app, you know, would need to, uh, request, 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 I'm   not that familiar with that's how possible that 
is, but but let's say I'm searching for music, uh   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 web server. It's going to go there, and then that 
web server is going to do a query, issue a query, uh   translated query to, 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 there is. And let's say that I found   it, it finds, I don't know, 100 
songs that match my, uh, request for   uh, uh Korean pop music or something like that. 
And so I, 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 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 uh to the metadata database and do 
this query, and because it's a relational database,   that that query can happen pretty efficiently. 
Etc. so now I'm I return that information back,   and that and then I display that to the 
user. Does that does that seem does that   make sense in terms of finding music? 
Yeah, yeah, that makes sense. That's good, um, okay. And so now I have a list of songs, and 
maybe I maybe there's like the one of the ones   in that list is like, Oh yeah, that's what I was 
looking for, and so I click on that uh song to   play it. I want to I want to hear that hear the 
song, so that's that second sort of part of the

use case that we talked about, which is playing music. So now, to play music, now this gets a little interesting, and this is I think I'm going to wind up maybe changing what I'm thinking about here a little bit, but let me talk through it. So I click on the play button, or I click on the song to play it, and that translates into a request from the app to the web server to start playing a song, playing the song, and it has an ID, like I mentioned, as an ID in it. And so now the web server, based on that song information ID, maybe has to go to this database here to look up the link. Uh, what did I call it? Oh, an audio link, maybe that's an Mp3 link, I don't know, something like that, that's a better term for it, I don't know. So the Mp3 link, and so that Mp3 link or audio link would be returned, and now the Spotify web server has to

go to the database where the actual audio is stored. Fetch that, fetch that database now. You could imagine streaming that five megabytes from this database, so chunk by chunk it comes back, and chunk by chunk it goes up to the Spotify app. In order to do this, you need like a websocket connection, so you need a kind of a long-standing connection between the application and this web server so that you can chunk that, you can send the data back in chunks. But I'm not sure whether I would need to do that or whether because it's only five megabytes, that's possibly small enough to just fit in memory, you know, read from the uh from S3 and fill fit into memory, and then have that particular web server chunk it back from there. I think that might be better because it would eliminate the possible lag between the database, so you don't start streaming the audio until you have it in memory. That might be something that I would consider doing.

so now let me think about so that that would be does that make sense in terms of like the playing like you're you start playing and obviously you can control it you can pause playing and so on but does that make sense so you you you start playing the web server gets the request to play it maybe gets the information about where to go over here to get the the S oops the S3 uh storage audio storage reads that back it's only five megabytes that should be should not take it should be almost instantaneous and then it starts streaming that back to the application does that make sense yeah that makes sense uh please please carry on yeah so all good so far Okay so this almost sounds too good to be true or sounds too easy I I think it's got to be more complicated than that okay so one thing I'm just realizing here is uh probably out of these what did we say we said 100 million songs

there's there's probably a lot of stuff that is, uh. I'm going to use the term Indie artists or something like that. Stuff that few people, uh, not very many people listen to or isn't very popular, and on the flip side of that, I'm thinking about like what could go wrong here. Well, if, uh, like BTS, which is, again, a Korean pop, pop band, uh, if they, let's say they release a new song and it's like, Hey, everybody wants to listen to this, is super, oh, have you heard the latest song, etc. If you've got all of these web servers all fetching that same thing, uh, that same song, and let's say you've got, you know, requests like it's released and in the next minute you've got, I don't know, uh, how do we, you said a billion users, okay, let's say that, uh, 10 million users all request the song all at the same time or something like that because it's just been released and they're

following you know social media is something you 
could easily overload in terms of bottlenecks you   could Pro you could overload possibly uh that 
bucket or that bucket excuse me that particular   uh song uh that file or whatever however it's 
stored in AWS and it could be stored different   ways I'm using it S3 here you could overload uh 
AWS or S3 there and you could also possibly be   you know like streaming like loading up all these 
these web servers with the same song streaming the   same thing back so it's a lot of bandwidth Etc so 
a better thing to do and a common thing to do for   stuff like this is to to use what's called a CDN 
content delivery Network which is like a it's a   cache so this this helps reduce the amount of load 
on on back ends so let me draw something here let   me just I am going to pick uh what shape am I 
going to pick I'll just pick randomly something

like this so maybe over here so I'm going to say 
here this is a CDN which is an song audio cache. This is typing in and so what would happen. So and 
by the way the Technologies here just to this this CDN, a Content delivery network is usually 
very very close in terms of number of hops and network connections to users. So what would happen 
is let me draw another arrow here and let me draw uh an arrow down to here so what what would happen 
here is that the first time that this song is this newly released single is requested, the 
web server would read it and stream it like normal, but probably we need to make sure that 
these Spotify web servers are somewhat uh they're keeping track of things and they're 
keeping track of you know which songs are being requested, which ones are hot. They probably have a 
heat map the most recently requested songs and so in that heat map as they see oh this song 
is now ever I've seen this requested, the

fifth third time in you know in a minute or something like that at that point in time what it might do is it might actually uh instead of just streaming it back to itself or copying it back to itself excuse me it might actually load that into the CDN and so I am trying to I'm going to have to draw another arrow I think in order to do that because these things probably have to talk to the CDN and by the way I'm not a super expert on this area in terms of how this works but there's some connection between this Edge caching this content delivery Network which is just there for caching and these Spotify web servers so these web servers are going to somehow notify the CDN hey you should be pulling this song this BTS latest song pull that from uh the MP3 the audio storage so the CDN you know would load that up and this now has to work in conjunction with the application so that means that the application when it when

the person decides when I request the song I want 
to play this latest BTS song, and I haven't had it   on my phone yet. It's just been released. Before 
I go and I talk to the web server, I might even   go and check in this application. I might 
actually go and check in this content delivery   Network to see, is it there? It might also be so, 
and if it is there, then I just read it from there.   The other option, and again this 
is technology that I'm sort of not super familiar   with, is that it goes and asks the web server, 
just like it normally would, and the web server   sends back a redirect saying, Hey, I don't have 
it, but you should go over here to this content   delivery Network, this Edge cache, to fetch the song. It's much closer to you. You'll   get better performance, and you won't be loading 
me up so much. So, I've got a lot of arrows here.

but uh, the standard flow for a song. First time around is, you know, coming around, getting the metadata going around to reading the audio data. The web server is now keeping track and realizing, oh, you know what, this is getting. I'm getting multiple requests for this same song. Now I'm going to tell the CDN, go and fetch this song. It's going to fetch it. And so now, the application can, I can, it can be redirected, for example, to read that audio from there. So that's a lot of talking, but I was realizing that caching here seems like it's a very important point in this design and would help with the bottleneck of hot songs, if you will. Does that, is that absolutely, yeah. By the way, that's a really good answer. Okay. And there's, again, in the AWS family here, I'm going to use the family. You know, obviously, if I were a Googler, you know, I might not be using this, but there's a technology called CloudFront.

and CloudFront is basically a Content delivery Network. There's a bunch of other ones. Uh, gosh, Flask, is that what it is? I can't remember what the names of these of these Technologies are, but there's a bunch of other technologies that are very similar in nature that allow you to do this, so that would help with the bottlenecks and uh in terms of the caching here. You could also, and this is part of the reason, by the way, I just stepping backwards here a little bit, part of the reason why I think it would be better initially when the web server is getting the song for the first time for it to read the entire MP3 into its memory because then if it's, if if it is getting multiple requests for a particular song, uh, then it doesn't have to go to the database. It can actually just feed it from from its memory, and that's also a form of caching, of course, so it's

got a local cache, essentially of uh of these songs, and you could imagine having a shared cache that's shared across these web servers, so we that could be another optimization, but my point is that if we have a cache in memory in these web servers that stores the songs, then we're offloading the database a little bit. If we then have the cache here at this the edge of the network, so this is that's what it's called Edge Network Edge caching, then we're offloading the web servers to a large extent because the streaming this is optimized for streaming and so on. And I think if we go one step further, actually I'm, I'm sure, and if I were designing it, I would design the application because these are on smartphones, uh, to store the songs that are played frequently by the specific user locally in the local storage, so it's another form of caching. So then if it finds the song in the local in its local cache, essentially local store here on the phone, uh, then

you know you you wouldn't even need to go to the 
to the network at all right. So you could actually, I'll even draw like this so it's like a little 
little cash, a little local storage here of songs. So there's multi-layer caching. I guess what I'm 
saying, multiple levels of caching, ultimately with 
the goal to provide the best user experience, 
make sure it's super fast, and to then offload 
obviously the system to, to allow it to sort of 
scale and limit costs, etc. So that's probably 
enough on caching, and I think I've gone 
gone, you know, gone deep a little bit there. 
Be ready for the interviewer to ask you about 
particular components or different aspects of your 
system, and to talk in detail about them. It's also 
good to talk through the flow of a particular use 
case. This helps make sure the interview is clear 
on it, but also helps you test your design as you 
talk through it, as well as helping you identify 
any potential bottlenecks, as it did with Mark here.

Mark explained the purpose of the caching and also where caches might exist in the system. Caching wasn't limited to the CDN and the app, but also the web server. He could have talked about caching the metadata as well as the song data. We've done caching, uh, that's all good. Uh, now I wanted to ask you about load dancing. Uh, yeah, how would you think about load balancing for this particular app? Yeah, magic load balancing. It's, uh, yeah, a little, a little bit of hand-wavy here. I think of load balancing. I mean, so load balancing, uh, commonly is used to. The load balancer's job here really is to make sure that these web servers are don't are not overloaded so that they're providing good service to the end users and they're not overloaded. And overloaded can can mean many things. Often it's in terms of CPU. So, you know, you're getting requests in, lots of requests coming in, uh, and if if you're getting lots of requests coming in, then just load balancing these requests.

across the server so that there's roughly the same 
number of requests on each one. Assuming they're   all equal would probably also result in the CPU 
utilization being about equal. I think for this   application, I would think about load balancing. 
I might think about it a little bit differently   because we're streaming data, and so I might be 
not instead of using CPU as my load balancing   metric to figure out how to distribute the load. 
I might be looking at possibly Network bandwidth,   like is because if a particular web server 
is not doing a lot from a CPU perspective, but   if it is I/O bound or network bound, meaning 
it's hitting its limit of its if it of its   a network connection, then I wouldn't want the 
load balancer to send it more traffic because   it's just going to bog down, and you're going to 
get skips and things like that. So I might make   this load balancer aware of multiple metrics, one 
of them being Network, maybe memory for caching.

although you could probably you can kind of limit 
that possibly, but maybe not CPU for this purpose. It might be requests out outstanding or current 
streams or something like that. There might be some other metrics, but I'd want to. I would want to 
make this load balancer maybe a little bit smarter than just a typical request, uh, round robin load 
balancing scheme. So I'm not sure if that's getting it what you're asking. Yeah, yeah, I think that 
answers my question. Load balancing is not a one size fits all. Mark mentioned looking at different 
metrics as a way to load balance across different servers, which was a clever approach. Mark was very 
open about the fact that load balancing isn't an error. He's an expert on, and this is okay. It's fine 
to be honest when you ask about things that are at the limits of your knowledge. Okay, cool, yeah, 
all right. Are you done with your design, or is there anything else that you want to add? 
Yeah, let me think about that and give me give me

just a moment. I mean it again. you know I've way oversimplified this but ah. I guess I think if I were to also think about this at a global scale. I mean Spotify is a global app and so it's it's possible. so uh replication. I didn't really talk about replication other than to do the math to say hey maybe three three x replication and replication right. why do we do this. well we do do it to make sure that we have uh data available when there's an outage. so if so you know if I if I were to you know I mean like do this right to indicate three replicas. but that's that's a little naive. and the same thing for the metadata of course. but the replicating the data is not just for availability and downtime. it's also you would want to place those replicas closer to where the users are. and so from a Global Perspective you might have music that

is more local like maybe European punk rock is, you know, more listened to more in Europe and maybe maybe BTS is, you know, because it's Korean pop, is maybe it's more popular actually in Korea or in Asia, and so you might want to have the replicas of those songs, uh, and maybe even the metadata be more locally, uh, represented more locally, so that you can get to it faster. You don't have to cross an ocean to get to the to the data, and, uh, you know, to reach it. So kind of a Geo-aware strategy of data placement and possibly replication strategy that might be a a refinement, I think, that I would might make to this design to make it just a little bit more, uh, performant, effective, etc., etc. So yeah, does that does that make sense? Yeah, yeah, I think nothing is just interesting point to add it's a good idea to wrap up your answer by referring back to the requirements laid out at the beginning of the interview and confirming that your design meets

them if you have time. It's always nice to think 
big and take a quick look at the problem from a   different dimension. That could make it more 
complex. Mark did this with his geolocation   idea. He didn't go into detail, but another interviewer 
might have explored this further. And it could have   opened up a whole new aspect of the design. Overall, 
an excellent answer from Mark. Yeah, great job Mark.   I think that was a really good approach. And 
yeah, how did you feel now, now looking back now,   the interview is over. Let's say you've 
uh, you've walked out the interview room   and read the big sigh of relief. How 
how are you feeling that it's gone? I feel pretty good about it. It's, uh, yeah, it's 
definitely different being on the other side of   things. And, uh, I know that I'm sure I miss things 
and I'm, I'm, you know, people are watching this. And   and, uh, wind up scheduling some a session with me. 
I'm, you know, happy to take the feedback on.

some things that I missed. I'm sure I've missed things, but uh, but yeah, it's fun. Fun to do this though. Cool, good stuff. Well, uh, yeah, thanks very much. And, uh, yeah, thanks everyone for watching. Hello. I really hope you found that useful. If you did, you can like and subscribe. And why not come visit us at igotanoffer.com. There you can find more videos, useful frameworks, and question guides, all completely free. And you can also book expert feedback one-to-one with our coaches from Google, Meta, Amazon, etc. Thank you and good luck with your interview. [Music] All right. [Music]

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.



IGotAnOffer: Engineering

Spotify 디자인하기: 시스템 설계 모의 인터뷰

Google의 엔지니어링 매니저였던 Mark는 음악을 찾고 재생하는 사용 사례에 초점을 맞춰 Spotify의 고품질 시스템 설계에 대한 답변을 제공합니다.

그는 노래, 재생 목록, 사용자, 아티스트, 팟캐스트 등 Spotify의 다양한 측면에 대해 논의하는 것으로 시작하지만 구체적인 사용 사례로 범위를 좁혀갑니다.

Mark는 제한된 시간 내에 설계를 해결할 수 있도록 문제를 제약하는 과정을 효과적으로 보여줍니다.

또한 토론 중에 10억 명의 사용자와 1억 곡과 같은 지표를 고려하면서 디자인 프로세스의 세부 사항에 대한 그의 관심을 보여줍니다.

음악 스트리밍 서비스를 위한 오디오 데이터 규모 추정하기

일반적인 노래 한 곡은 약 5메가바이트이며, 1억 곡의 경우 총 오디오 데이터는 약 500테라바이트 또는 0.

5페타바이트의 원시 오디오 데이터가 됩니다.

각 노래의 메타데이터는 총 10기가바이트 정도로 작으며, 10억 명의 사용자에 대한 사용자 메타데이터는 약 1테라바이트가 됩니다.

Spotify의 시스템 아키텍처에는 웹 서버, 로드 밸런서, 오디오 데이터 및 메타데이터를 저장하는 데이터베이스가 포함됩니다.

데이터베이스는 노래 오디오 데이터베이스와 메타데이터 데이터베이스의 두 부분으로 나뉘며, 각각 다른 유형의 데이터를 제공합니다.

확장성과 불변 데이터에 적합하기 때문에 MP3 파일을 저장하는 데는 Amazon S3를 사용하고, 메타데이터 데이터베이스는 사용자 정보를 저장하고 보다 복잡한 쿼리를 지원하기 위해 사용됩니다.

노래 메타데이터와 오디오 데이터를 별도로 저장하면 효율적인 쿼리 및 업데이트가 가능합니다.

웹 서버는 오디오 데이터에 액세스할 필요 없이 관계형 데이터베이스를 쿼리하여 사용자 요청에 따라 노래 목록을 찾아서 반환할 수 있습니다.

이러한 설계 덕분에 사용자가 음악을 찾고 재생하는 과정이 원활하게 이루어집니다.

웹 서버에서 음악을 재생하는 과정

사용자가 노래를 재생하기 위해 클릭하면 앱은 웹 서버에 요청을 보내 노래 재생을 시작하고 데이터베이스에서 오디오 링크를 검색합니다.

그러면 웹 서버는 데이터베이스에서 오디오를 가져오고, 크기에 따라 웹소켓 연결을 사용하거나 메모리에 저장하여 애플리케이션으로 다시 스트리밍할 수 있습니다.

CDN(콘텐츠 전송 네트워크)을 사용하면 백엔드의 부하를 줄이고 인기 있거나 덜 인기 있는 노래에 대한 스트리밍 프로세스를 최적화할 수 있습니다.

새로운 음악 스트리밍에서 콘텐츠 전송 네트워크의 역할

CDN(콘텐츠 전송 네트워크)은 새로 출시된 음악을 스트리밍하는 데 중요한 역할을 하며 웹 서버의 부하를 줄여줍니다.

노래가 처음 요청되면 웹 서버는 후속 요청의 성능을 개선하기 위해 CDN에 노래를 저장할 수 있습니다.

CloudFront와 같은 CDN은 병목 현상을 줄이고 인기 곡의 스트리밍을 최적화하는 데 필수적입니다.

첫 번째 요청 시 전체 노래를 웹 서버의 메모리에 저장하는 것도 효율성을 개선하기 위한 일종의 캐싱 역할을 합니다.

노래 스트리밍을 위한 다단계 캐싱

캐싱은 성능을 최적화하고 시스템 부하를 줄이기 위해 웹 서버, 네트워크 에지, 사용자 스마트폰에서 로컬로 수행될 수 있습니다.

다단계 캐싱 시스템의 목표는 빠르고 원활한 사용자 경험을 제공하는 동시에 네트워크 요청의 필요성을 최소화하는 것입니다.

마크의 캐싱 접근 방식은 여러 계층을 포함하며 전반적인 시스템 효율성과 사용자 경험을 개선하기 위해 설계되었습니다.

글로벌 규모의 앱을 위한 데이터 복제의 중요성

데이터 복제는 정전 시 가용성을 보장하고 복제본을 사용자에게 더 가까운 곳에 배치하여 데이터에 더 빠르게 액세스할 수 있도록 하는 데 매우 중요합니다.

데이터 복제에 대한 글로벌 관점에서는 콘텐츠의 현지 인기도에 따라 복제본을 전략적으로 배치하여 장거리를 이동할 필요 없이 더 빠르게 액세스할 수 있도록 합니다.

지역 인식 데이터 배치 및 복제 전략의 설계를 개선하면 특히 지리적으로 다양한 사용자 기반에서 앱의 성능과 효율성을 크게 향상시킬 수 있습니다.