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.



IGotAnOffer: Engineering

시스템 설계 인터뷰에서는 문제 범위를 한정하고, 특정 사용 사례에 집중하여 1시간 내에 해결 가능한 수준으로 논의를 진행해야 합니다.

데이터베이스를 오디오 데이터(불변 파일)와 메타데이터(업데이트 및 쿼리 가능)로 분리하는 것은 액세스 패턴, 데이터 크기, 필요한 쿼리 유형이 다르기 때문에 효율적인 설계 방식입니다.

인기 있는 노래로 인한 병목 현상을 해결하고 사용자 경험을 개선하기 위해 CDN(콘텐츠 전송 네트워크)을 통한 다계층 캐싱(웹 서버, 엣지 캐시, 로컬 기기) 전략을 사용하는 것이 중요합니다.

시스템 디자인 모의 인터뷰 소개

본 시스템 디자인 모의 인터뷰는 Google 전 엔지니어링 관리자 Mark와 함께 진행되며, **최고 수준의 시스템 디자인 답변을 제시하여 인터뷰 준비에 도움을 주는 것**을 목표로 합니다. Mark는 Google에서 13년간 엔지니어링 관리자로 재직하며 다양한 대규모 시스템을 다룬 경험이 있습니다.

Spotify 디자인: 초기 설정 및 범위 한정

인터뷰 질문은 'Spotify를 어떻게 디자인할 것인가?'였습니다. Spotify는 음악 스트리밍 외에도 재생 목록, 사용자, 아티스트, 팟캐스트 등 다양한 측면이 있지만, **한정된 시간 안에 효율적인 답변을 위해 '음악 찾기 및 재생' 기능에 집중하여 설계 범위**를 좁히기로 했습니다.

설계를 시작하기 전에 시스템의 규모를 파악하기 위해 몇 가지 가정을 세웠습니다. **사용자는 10억 명, 노래는 1억 곡**으로 설정했으며, 일반적인 MP3 오디오 파일 하나당 5MB로 가정했습니다. 이 가정을 통해 총 오디오 데이터는 약 0.5PB, 3배 복제 시 1.5PB가 될 것으로 추정했습니다. 노래 메타데이터는 100바이트로 가정하여 약 10GB, 사용자 데이터는 사용자당 1KB로 약 1TB로 예상했습니다.

핵심 구성 요소 및 데이터베이스 설계

Spotify 시스템의 기본적인 구성 요소는 **사용자 휴대폰 앱, 로드 밸런서를 거치는 Spotify 웹 서버, 그리고 데이터베이스**입니다. 특히 데이터베이스는 메타데이터와 오디오 데이터의 특성이 달라 두 가지로 분리하기로 했습니다. 이는 고수준 설계 단계에서 중요한 의사결정으로, 면접관이 쉽게 이해할 수 있도록 그림과 말로 소통하는 것이 중요합니다.

**노래 오디오 데이터는 불변 데이터**이므로 Amazon S3와 같은 Blob 저장소에 적합합니다. S3는 확장성이 뛰어나고 대부분 읽기 전용 액세스 패턴에 최적화되어 스트리밍에 용이합니다. 반면, **사용자 정보나 노래 제목, 아티스트 같은 메타데이터는 업데이트가 필요하고 쿼리가 빈번**하므로 Amazon RDS와 같은 관계형 데이터베이스에 저장하는 것이 효율적입니다. 이러한 분리는 액세스 패턴, 데이터 크기, 필요한 쿼리 유형의 차이점을 고려한 것입니다.

음악을 찾을 때, Spotify 앱은 아티스트 이름이나 장르 등으로 필터링된 **'음악 찾기 요청'을 웹 서버로 보냅니다.** 웹 서버는 이 쿼리를 관계형 메타데이터 데이터베이스로 전달하여 관련 노래 목록과 메타데이터를 다시 앱으로 반환합니다. 이 과정에서 MP3 오디오 데이터베이스는 접근하지 않습니다.

노래를 재생할 때, 앱은 특정 노래 ID를 포함한 **'노래 재생 요청'을 웹 서버로 보냅니다.** 웹 서버는 메타데이터 데이터베이스에서 해당 노래의 오디오 링크를 찾아 실제 오디오 데이터가 저장된 S3와 같은 저장소에서 파일을 가져옵니다. 5MB 정도의 노래는 거의 즉시 가져올 수 있으며, WebSocket 연결을 통해 앱으로 스트리밍을 시작합니다. 이 과정에서 웹 서버는 메모리에 파일을 캐싱하여 데이터베이스 부하를 줄일 수 있습니다.

인기곡이 동시에 많은 요청을 받을 경우 발생할 수 있는 병목 현상을 해결하기 위해 **CDN(콘텐츠 전송 네트워크)을 통한 캐싱 전략이 필수적**입니다. 처음 요청되는 노래는 웹 서버에서 정상적으로 스트리밍하지만, 특정 노래가 자주 요청되면 웹 서버는 CDN에 해당 노래를 로드하도록 지시합니다. 이후 앱은 CDN에서 직접 오디오를 가져와 웹 서버의 부하를 줄이고 성능을 향상시킵니다.

CDN 외에도 여러 계층의 캐싱을 고려할 수 있습니다. 웹 서버 메모리에 인기곡을 캐싱하여 데이터베이스 접근을 줄이고, **사용자 휴대폰 로컬 저장소에도 자주 듣는 노래를 캐싱**하여 네트워크 트래픽을 최소화할 수 있습니다. 이러한 다층 캐싱은 사용자 경험을 향상시키고 시스템 부하를 줄여 확장성과 비용 효율성을 확보하는 데 기여합니다.

로드 밸런서는 웹 서버에 과부하가 걸리지 않도록 요청을 분산하는 데 사용됩니다. 일반적인 CPU 사용률 외에도 Spotify와 같이 **데이터 스트리밍이 주된 서비스에서는 네트워크 대역폭을 로드 밸런싱 메트릭으로 고려**하는 것이 중요합니다. 또한 미해결 요청 수나 현재 스트림 수 등 다양한 메트릭을 활용하여 라운드 로빈 방식보다 더 스마트하게 로드를 분산할 수 있습니다. 자신의 지식 한계를 솔직하게 밝히는 것도 좋은 자세입니다.

Spotify가 글로벌 앱이라는 점을 고려할 때, **데이터 복제는 단순한 장애 대비를 넘어 지리적 위치 인식 전략**으로 활용될 수 있습니다. 인기 있는 지역 음악이나 아티스트의 노래 복제본 및 메타데이터를 해당 지역 사용자에게 더 가깝게 배치하여 액세스 속도를 높이고 네트워크 지연을 줄일 수 있습니다. 이러한 지리적 복제 전략은 시스템의 성능과 효율성을 크게 향상시킬 것입니다.

인터뷰를 마무리할 때는 처음에 제시된 요구 사항을 다시 언급하고, 설계가 해당 요구 사항을 충족하는지 확인하는 것이 중요합니다. **시간이 허락한다면, Mark가 지리적 위치 아이디어를 제시한 것처럼 문제를 더 복잡하게 만들 수 있는 다른 차원을 빠르게 살펴보는 것도 좋습니다.** 이는 면접관에게 깊이 있는 사고 능력을 보여줄 수 있는 기회가 됩니다.

Spotify 시스템 디자인 인터뷰에서 Mark가 범위 설정을 위해 음악 찾기 및 재생에 집중하기로 결정한 이유는 무엇인가요?

Mark는 Spotify 시스템의 고수준 구성 요소를 설명할 때, 오디오 데이터베이스와 메타데이터 데이터베이스를 분리한 주된 이유는 무엇이며, 각각 어떤 기술을 활용했나요?

인기곡 요청으로 인한 병목 현상을 해결하기 위해 Mark가 제안한 캐싱 전략에는 어떤 종류들이 있으며, 각각의 역할은 무엇인가요?

Mark는 로드 밸런싱에 대해 설명하면서 일반적인 CPU 사용률 외에 어떤 다른 메트릭을 고려해야 한다고 언급했나요?

전 세계적인 Spotify 앱 환경에서 Mark가 데이터 복제 및 배치 전략에 지리적 인식을 도입해야 한다고 제안한 이유는 무엇인가요?

안녕하세요. 이번 시스템 디자인 모의 인터뷰에 오신 것을 환영합니다. 오늘은 여러분이 인터뷰를 준비하고 어떤 수준을 목표로 해야 하는지 정확히 알 수 있도록 최고 수준의 시스템 디자인 답변을 보여드리고자 합니다.

오늘 답변을 해주실 분은 전 Google 엔지니어링 관리자이신 Mark입니다.

Mark, 잘 지내시죠? 네, Tom, 초대해 주셔서 감사합니다. 이 시간이 기대됩니다. 와주셔서 감사합니다. 모시기 돼서 정말 기쁩니다. 시작하기 전에 엔지니어링 관리자로서의 경력에 대해 간략하게 설명해 주시겠어요?

네, 저는 Google에서 13년 동안 엔지니어링 관리자로 일하면서 많은 훌륭한 엔지니어들과 함께 여러 대규모 시스템을 작업했습니다.

그래서 저는 그들로부터 조금이나마 배웠기를 바라며, 인터뷰 응시자가 되는 반대편에 서 있는 제 모습을 보는 것이 흥미로울 것입니다. 기대됩니다.

분명 잘 해내실 겁니다. 네, Mark는 저희 플랫폼의 코치이기도 합니다.

Google, Facebook, 어떤 기술 회사든 인터뷰 전에 전문가의 피드백이 필요하시면 저희 플랫폼에서 확인해 보세요. 자, Mark, 준비되셨다면 바로 시작해 볼까요?

오늘 제가 드리고 싶은 질문은 Spotify를 어떻게 디자인하시겠습니까? 좋습니다. Spotify는 아마도 가장 인기 있는 음악 스트리밍 서비스 중 하나일 겁니다.

잠시만 생각해 보겠습니다. Spotify에는 많은 측면이 있기 때문입니다. 제가 메모를 좀 하면서 생각을 정리해도 될까요?

메모가 준비되었습니다. 여기에 적어두겠습니다. 괜찮으시다면 이것을 메모와 디자인 다이어그램 등으로 활용하겠습니다.

네, 좋습니다. 네, 그럼, 네, 그럼, 스포티파이에 대해 이야기해 보죠. 좋아요, 스포티파이의 경우, 노래, 음악이 가장 중요하다고 생각합니다.

재생 목록도 있고, 사용자도 있고, 아티스트도 있습니다. 스포티파이에는 팟캐스트 같은 것도 있어서 들을 수 있죠.

할 게 많습니다. 오늘 시스템 디자인과 관련해서, 디자인을 실제로 완료할 수 있도록 범위를 좀 좁힐 수 있을까요?

여기서 무엇에 집중하는 것이 좋을까요?

네, 범위를 좁히겠습니다. 음악을 찾고 재생하는 데 집중하죠. 좋습니다. 그럼, 사용 사례, 찾기, 음악 재생. 여기 그대로 적어두겠습니다.

좋습니다. 네, 이야기할 거리가 충분한 것 같습니다. 네, 좋아요. 그럼, 생각해 보면, 사용 사례에 대해 좀 더 묻거나 생각해 보겠습니다.

스포티파이에 가입한 사용자인 제 일반적인 사용 사례는 휴대폰 앱에서 음악을 탐색하고, 특정 노래를 검색하고, 노래를 재생하는 것입니다. 그러면 휴대폰, 자동차, 헤드폰 등으로 음악이 다시 재생되겠죠.

이처럼 광범위한 질문의 경우, 문제를 제한하고 한 시간 안에 해결할 수 있도록 해야 합니다. 마크는 집중하고 싶은 사용 사례를 설정하여 이 점을 잘했습니다.

이미 존재하는 시스템(이 경우 스포티파이)을 설계하라는 요청을 받으면 인터뷰 담당자에게 알고 있는 내용을 공유하세요.

지식 격차가 있는 경우 수정하거나 채워줄 수 있습니다. 다른 것을 생각해 보면, 여기서 메트릭, 크기를 생각해 보겠습니다.

자, 여기서 몇 가지 숫자를 빠르게 살펴봅시다. 양해를 구합니다. 숫자로 말하자면, 이 설계를 위해 생각하고 있는 사용자 수가 얼마나 됩니까?

네, 10억 명이라고 합시다. 좋아요, 10억 명의 사용자. 좋아요. 노래 수는요? Spotify에 약 8천만 곡이 있다고 들었는데, 1억 곡을 담을 수 있는 용량이 필요하다고 합시다.

좋아요, 1억 곡, 10억 명의 사용자, 그리고 노래에 집중할 겁니다.

여기서 약간의 계산이나 생각을 해보고, 말이 되는지 확인하기 위해 다시 한번 확인해 보겠습니다.

제가 알기로는 일반적인 MP3 오디오는 일반적인 노래의 경우 약 5MB 정도 될 것입니다.

노래의 인코딩 방식, 노래 길이 등에 따라 달라지겠지만, 괜찮다면 그렇게 가정해도 됩니다.

괜찮으시겠어요? 네, 좋습니다. 96kbps처럼 매우 낮은 품질에서 320kbps까지 인코딩할 수 있습니다.

하지만 중간 정도인 128~160kbps가 그 정도 될 겁니다. 좋아요, 그렇게 가정합시다.

그럼 여기서 추론해 봅시다. 노래당 5MB이고, 1억 곡이 있다면요.

제 생각에는, 계산을 해보려고 하는데, 1억 곡은 1,000배인 1,000억 곡이 되고, 100조 곡은 100만 배, 5를 곱하면 500조 곡이 됩니다.

총 오디오는 약 500TB 정도이고, 이는 0.5PB의 데이터와 같습니다.

그래서 제가 그런 가정을 하고 있습니다. 데이터를 복제하는 방식에 따라, 일반적으로 이러한 노래들을 여러 개 가지고 싶어 하실 텐데요. 여러 개의 복사본을 가지고 있어야 손실되지 않고, 일부 복제본이 다운되는 경우에도 대비할 수 있기 때문입니다.

예를 들어 3배 복제를 한다고 가정하면, 원시 오디오 데이터가 1.5페타바이트가 됩니다.

그리고 각 노래의 메타데이터, 즉 노래 제목이나 아티스트와 같은 정보는 크기가 크지 않을 겁니다.

아마 노래당 100바이트 정도의 메타데이터가 될 것 같습니다.

그래서 계산해 보면, 10억, 100억 곡이 있다면 10기가바이트 정도의 노래 메타데이터가 됩니다.

만약 1킬로바이트라고 해도 100기가바이트 정도니까, 여전히 큰 용량은 아닙니다. 다시 한번 계산해 보겠습니다.

1억 곱하기 100, 정말 100바이트일까요? 네, 10기가바이트 정도가 될 것 같습니다. 극단적으로 올려잡아서 100기가바이트라고 해도 큰 데이터는 아닙니다.

사용자 데이터의 경우, 사용자당 1킬로바이트 정도의 메타데이터가 있을 수 있습니다. 결국 다 메타데이터죠.

10억 명의 사용자를 곱하면 약 1테라바이트의 데이터가 됩니다.

이것은 대략적인 규모를 파악하기 위해 간단하게 계산해 본 것입니다.

지금까지 이해가 되시나요? 괜찮은 것 같나요? Mark처럼 고수준 설계를 시작하기 전에, 시스템 규모에 영향을 미칠 수 있는 고수준 의사 결정을 파악하는 데 도움이 되는 몇 가지 지표를 얻으십시오.

마크는 사용자 수와 노래 수에 대해 올바른 질문을 했습니다. 저는 숫자에 얽매이지 않고 대략적인 계산을 했습니다.

마크가 계산하지 않은 것은 트래픽, 즉 하루 또는 심지어 초당 스트리밍되는 노래 수였습니다. 그것은 그가 웹 서버의 확장, 그가 얼마나 많이 필요할지, 그리고 그가 얼마나 많은 대역폭이 필요할지를 알아내는 데 도움이 되었을 것입니다.

하지만 이것이 그의 개략적인 설계에 영향을 미치지 않았기 때문에 이 시점에서 확장에 대한 세부 사항을 자세히 다루지 않아도 괜찮았습니다.

좋아요, 기본적인 구성 요소에 대해 생각해 보겠습니다. 그림을 그릴 건데, 나중에 좀 더 자세히 설명할게요.

좋아요, 제가 생각하는 몇 가지 기본적인 구성 요소가 있습니다. 먼저 휴대폰을 최대한 비슷하게 그려보겠습니다. 여기에 Spotify 앱이 있습니다. 크기를 줄여서 안에 들어가게 하겠습니다.

일반적으로 휴대폰에 있는 앱이 있습니다. 여기서는 휴대폰 앱에 대해 이야기한다고 가정하겠습니다. 왜냐하면 그것이 매우 일반적이기 때문입니다. 그래서 휴대폰이 있습니다.

휴대폰은 Spotify 애플리케이션 서버 또는 웹 서버와 통신합니다. 여기에 Spotify 웹 서버가 있다고 가정해 보겠습니다.

웹 서버는 하나만 있는 것이 아니라 많이 있을 것입니다. 많다고 가정하겠습니다.

그리고 클라우드에서 애플리케이션을 사용할 때 일반적으로 하는 것처럼 로드 밸런서가 있습니다. 그려보겠습니다.

화살표가 있다고 가정하고, Spotify 앱이 로드 밸런서를 통해 웹 서버와 통신한다고 가정합니다. 이것들이 핵심 구성 요소입니다.

이것에 대해 좀 더 생각해 보겠습니다. 네, 지금까지는 좋습니다. 좋아요. 그리고 가장 중요한 것, 또는 가장 중요한 것 중 하나입니다.

모양을 찾을 수 있는지 보겠습니다. 찾았습니다. 좋은 모양입니다.

저는 이걸 그냥 데이터베이스라고 부르겠습니다. 그리고 이걸 조금 더, 음, 제가 원했던 건데요. 좋아요, 데이터베이스가 있습니다. 웹 서버는 데이터베이스와 통신하면서 정보를 읽고 쓰고 할 겁니다. 데이터베이스에서 정보를 읽고 쓰는 거죠.

이것들이 매우 높은 수준의 구성 요소입니다. 시스템 설계 인터뷰에서는 양방향 통신이 중요합니다. 즉, 그림과 말로 소통을 잘해야 합니다.

인터뷰 전에 이것을 철저히 연습해야 합니다. 마크는 이걸 잘했습니다. 그는 답변 초반에 구성 요소를 그리기 시작했고, 덕분에 면접관은 쉽게 따라올 수 있었습니다.

인터뷰의 이 시점에서는 더 간단하고 더 적은 구성 요소를 갖는 것이 좋습니다. 그런 다음 답변에서 나중에 분리할 수 있습니다. 마크가 데이터베이스를 둘로 나눌 때처럼요. 아마도 저는 이걸 생각하고 있을 겁니다. 분명히 지나치게 단순화되었고, 스포티파이를 재설계하지는 않을 겁니다. 아시다시피, 기존의 전체 애플리케이션을 그대로 재설계하지는 않겠지만, 데이터를 다시 생각하면서 좀 더 자세히 설명할 수 있을 것 같습니다. 왜냐하면 데이터가 중요하기 때문입니다.

그래서 저는 메타데이터와 사용자 데이터, 오디오 데이터를 생각하고 있습니다.

이것들은 매우 다른 유형의 데이터입니다. 그래서 저는 실제로, 여기 있는 이 데이터베이스를 두 가지로 나눌 겁니다. 그리고 그걸 설명하거나, 조금이라도 설명하려고 노력할 겁니다.

자, 됐습니다. 이걸 조금만 더, 음, 이걸 나눠서 노래 오디오 데이터베이스와 메타데이터 데이터베이스가 있다고 하겠습니다.

여기에는 사용자, 노래, 또 뭐가 있을까요?

궁극적으로 아티스트 등도 있겠지만, 우리는 음악, 노래 등에 집중하고 있습니다. 이것도 물론 데이터베이스입니다. 노래 오디오 데이터베이스와 메타데이터요.

그래서 제 생각에는, 이걸 조금만 더, 음, 이 스포티파이 웹 서버는 실제로 메타데이터와 오디오 데이터베이스와 통신할 겁니다.

사실 여기서는 두 개의 데이터베이스와 통신하게 될 겁니다. 네, 흥미롭네요. 왜 두 개로 나누는지 좀 더 자세히 설명해 주시겠어요?

네, 네, 그냥 가정하거나 그렇게 만들고 있습니다. 네, 좋아요. 제가 한번, 답변하고 싶습니다. 제가 사용할 기술 측면에서 생각해 보겠습니다.

여기서는 Amazon S3 같은 것을 사용하고 Amazon RDS를 사용할 수도 있습니다. 이제 그 의미를 설명하겠습니다. 실제 MP3 파일의 데이터 유형은 불변 데이터라고 생각합니다.

그것들은 단순히 데이터 덩어리, 파일, 대략 평균 5MB 정도의 파일이며 변경되지 않습니다.

그것들은 단순히 스트리밍되고, 저장되고, 기본적으로 스트리밍됩니다.

따라서 S3와 같은 Blob 데이터베이스는 그것에 매우 적합합니다. Google Drive와 같을 수도 있고, 문서와 같은 Blob 저장소 시스템과 같은 다른 기술도 있습니다.

하지만 Amazon S3는 그것에 매우 적합하며, 확장성이 뛰어납니다. 점점 더 많이 추가할 수 있고 선형적으로 확장되므로 매우 좋습니다.

데이터를 스트리밍할 수 있도록 연결할 수 있습니다. 따라서 그러한 유형의 데이터와 액세스 패턴은 대부분 읽기 전용입니다. 이 데이터를 스트리밍하기만 하면 됩니다.

왔다 갔다 하면서 데이터를 쓰지 않습니다. 그것이 바로 노래를 그런 종류의 데이터베이스에 넣고 싶은 이유입니다.

S3는 훌륭하고 매우 잘 작동합니다. 하지만 사용자 및 사용자 정보, 노래 및 노래 정보와 같은 메타데이터는 업데이트될 수도 있고, 특정 장르나 아티스트의 노래를 찾기 위해 쿼리를 해야 할 수도 있습니다.

또는 사용자를 업데이트하려고 할 수도 있습니다. 예를 들어 노래를 재생하고 있는데, 중단한 위치를 기억하여 다시 재생할 때 기억하도록 하고 싶습니다.

데이터를 상당히 많이 수정하거나 해당 데이터베이스 사이를 왔다 갔다 하면서 이러한 쿼리를 수행할 것입니다.

그리고 S3로는 쿼리를 제대로 할 수 없지만 관계형 데이터베이스에서는 가능합니다. MySQL도 또 다른 선택 사항이 될 수 있습니다. 어, 저는 여기서 그냥 RDS를 선택했는데, 사실상 Amazon의 관계형 데이터베이스를 선택한 이유는, 제가 여기서 AWS 제품군을 사용하고 있기 때문입니다.

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

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

스크립트