शैडोइंग अभ्यास: CAP Theorem in System Design Interviews - YouTube के साथ अंग्रेजी बोलना सीखें
C1
⏸ रुका हुआ
Hey everyone, welcome back to the channel.
200 वाक्य
यदि वाक्य बहुत छोटे या लंबे हों, तो समायोजित करने के लिए Edit पर क्लिक करें।
1
Hey everyone, welcome back to the channel.
2
I wanted to come on here and just take a quick moment to discuss CAP theorem, specifically in the context of system design interviews.
3
And so there's a lot of content on CAP theorem online, I'm sure you've read some of it, but most of which I find makes it way more daunting than it needs to be,
4
and none of which explains particularly well why it matters specifically in the context of a system design interview.
5
And so working with candidates every single day, as I do as the co-founder of Hello interview, it's shown me just how much confusion there is around this maybe seemingly simple topic.
6
And so I want to hop on here and see if we could solve that confusion for you all
7
kind of once and for all.
8
So if we turn our attention to the whiteboard, we can start with the very basic definition.
9
What is CAP theorem?
10
Well, CAP theorem states that you can only have two out of three of the following, consistency, availability, and partition tolerance.
11
So in a distributed system, as is almost always the case in our system design interviews, you'll have to choose two out of these three.
12
And so consistency, we'll get into more details on each of these later on, but consistency at a high level just means that all users see the same data at the same time.
13
Availability means that every request gets a response, whether it's successful or not.
14
And then partition tolerance is defined as the system works despite network failures between nodes.
15
Now why does this even matter in the first place?
16
Why do we care about CAP theorem in a system design interview?
17
That's because in a system design interview the first thing
18
that you're going to do is you're going to align on the requirements with your interviewer.
19
This is usually the functional requirements, the features of the system, and then the non-functional requirements which are the qualities of the system.
20
Now when you're going over the non-functional requirements the first thing you should do is start with CAP theorem.
21
You should ask yourself, does this system need to prioritize consistency or availability?
22
And the reason that's the question is because if we come back up here to cap theorem, partition tolerance in a distributed system is a must.
23
So we've chosen one out of our three.
24
And now the question that you in a system design interview need to wrestle with is simply, do I prioritize consistency in my system or do I prioritize availability?
25
And this ends up being really important
26
because it's going to have a significant influence on your design later on in the deep dives.
27
But why are these two things at odds with one another in the first place?
28
Why do we have to choose between consistency and availability?
29
Why not both?
30
Well, let's look at an example which will hopefully answer that question.
31
Imagine that you host a website.
32
This website has two servers, one located in the USA and one located in Europe.
33
Now, user A goes to write data to the server that they're connected to, located in the United States.
34
Let's say this data that they're writing is an update to their public profile.
35
Maybe they're just updating their name.
36
Once they do so, that data is replicated to the server in Europe, so that when user B goes to read the public profile of user A, they see that latest data, the updated name.
37
Easy.
38
Now, what happens if this network connection between these two servers gets severed for some reason?
39
It goes down.
40
And more importantly, what happens if it goes down before we had a chance to replicate that data,
41
that updated data from server A to the server in Europe?
42
Well, at this point, we as a system have a decision to make.
43
When user B goes to read this data, should we A, give them an error because this data is now stale
44
and so we don't want them to read stale data
45
or b do we just let them view the stale data
46
so writing that down in the case of a network failure should we a stop serving the data
47
if we choose that option then our system has prioritized strong consistency
48
if we chose
49
that we can just risk giving them wrong data seeing the
50
old name for a little bit until this is back online and figures itself out.
51
If that's okay, then our system chose availability.
52
So what are some examples where we would choose option A?
53
We would stop serving data because we prioritized consistency in the context of CapTheorem.
54
Well, the first option would be if it was like a ticket booking platform, either airlines or events, hotels.
55
And so imagine that what user A was doing when they wrote was that they were choosing seat 6A in an airplane.
56
and then our network failure broke.
57
Well, user B is looking to book a seat on the same flight, and if we showed them that seat 6A was still available when it's not, this would be catastrophic.
58
It would mean that they could book seat 6A
59
and both user A
60
and user B would show up to the airport on the same day thinking
61
that they're going to sit in the same seat.
62
Obviously a problem.
63
So in that case, we would choose consistency over availability.
64
What about like an inventory system like Amazon?
65
Imagine that you're down to your last item.
66
User A is buying the last toothbrush on Amazon.
67
If we have our network failure and user B goes and looks, they would see that there was one available and they would buy it too.
68
Now we only have one item, but we have two users that think that they bought it.
69
That's catastrophic.
70
Lastly, another common example is financial systems.
71
Imagine that user A goes to buy a stock and they hit the USA server.
72
User B goes to either buy or sell that same stock.
73
Well, the value of that stock, particularly if it's a low float, might have changed depending on the size of this sale in particular.
74
And so the order book needs to be kind of up to date.
75
And in this case, it wouldn't be.
76
So we need to choose strong consistency.
77
We should show user be an error as opposed to showing them out of date information.
78
Now, if you don't need strong consistency, then you would choose availability.
79
And this would be everything else.
80
Of course, this list isn't exhaustive.
81
But in the case where you don't need strong consistency, in the case where you can risk stale data, this is the overwhelming majority of cases.
82
Like our first example with profile data, so what if user B reads the wrong name for a little period of time? Who cares?
83
So anything like in a social media app, a user A posts some data, user B doesn't see their post for a while.
84
It doesn't see an update to their post.
85
No big deal.
86
What about a service like Yelp, where there's businesses that get reviewed?
87
And so maybe user A is a business and they're updating their business information.
88
And user B is a customer
89
and they're going to see slightly out of date business information for a couple seconds
90
or maybe up to a minute or
91
so it's totally fine we would rather show them the business
92
because we want that business then uh you know care
93
that one menu item is slightly out of date for a couple seconds same too with netflix what
94
if we change the description on a new movie
95
or we update a new movie or we add a movie is it okay
96
that the person in europe doesn't see it for a couple seconds
97
or they see something that's stale
98
or out of date for a couple seconds of course it is
99
and so what it comes down to in your interview is
100
that when you're going over your non-functional requirements you are asking yourself a simple question.
101
Does this system need strong consistency?
102
Does it matter that every single user sees the same state of my system at any given time and if they didn't, would it be catastrophic?
103
If the answer to that question is yes, you're going to prioritize consistency over availability.
104
If the answer to that question is no, then you're going to prioritize availability over consistency.
105
Great, you made your decision in your non-functional requirements.
106
You decided either to prioritize consistency or availability.
107
But how does this influence your design.
108
Now you have to go design the system.
109
Well, if you chose strong consistency, you're going to keep a couple things in mind.
110
You might need to implement distributed transactions.
111
So if you had, for example, a cache in a database, you need to ensure that those two things remain strongly consistent.
112
And so you'll have to guarantee that when a write happens to one, the write happens to the other, implementing a distributed transaction to ensure this.
113
You also might limit things to a single node.
114
Like maybe your database is a single instance.
115
if it's a single instance, then there can't be these propagation issues, right?
116
And so you'll do the math and you might say for my airline ticket booking system, I have a single database here.
117
And that single database is going to be something like a Postgres database
118
or a SQL database for which I can issue atomic transactions.
119
And this way, everybody views the same data because they're all reading from the same instance.
120
We also might need to just accept higher latency, right?
121
So So we're going to have to show users spinners or something while we're waiting for propagation to happen between instances.
122
And so some example tools or traditional relational database management systems, your Postgres, your SQLs, Spanner offered by Google is a great option.
123
Note that this doesn't mean if you have consistency, you can't go with NoSQL.
124
Many NoSQL databases offer strong consistency modes.
125
DynamoDB offers one of them.
126
It's controversial to some whether or not this would be the right choice.
127
In my opinion, it's totally fine.
128
Now what about if you ended up going with availability?
129
Well, if you go with availability, then you can use multiple replicas.
130
You're going to scale out your system and can have different read replicas.
131
And it's okay if there's propagation between those read replicas.
132
Eventual consistency is okay.
133
Things like CDC, change data capture, which is by definition eventually consistent, is okay to use in your system.
134
You're going to use things like DynamoDB, not with that strong consistency mode, but but with like multiple availability zones could be the configuration there.
135
Technologies like Cassandra, which are well optimized for high availability.
136
These are all good decisions if you decided to prioritize availability in your system.
137
Last thing before we wrap up here, I have some nuance to throw at you.
138
If you are a junior or mid-level candidate, you might want to just stop the video now.
139
I don't want things to get confusing.
140
If you're senior or up, then this is important to know.
141
And the important thing to understand here is that while we choose availability or consistency and those things are at odds,
142
we can have different parts of our system that prioritize different requirements.
143
So to make that clear, imagine Ticketmaster is a really good example.
144
In Ticketmaster, as we discussed, we want to prioritize consistency for booking tickets, because we can't have double booking.
145
We can't have two users thinking they have the same seat.
146
But there are other parts of our system for which we should prioritize availability, like for example, the CRUD on events, so creating, updating, deleting events.
147
If a user goes and updates the event description, it's okay if that's eventually consistent.
148
It's better that people can always view the event.
149
And so in a system design interview, you could be nuanced here with your interviewer.
150
And you could say, as it pertains to CAP theorem, I'm going to prioritize availability for searching and viewing events, but I'm going to prioritize consistency for booking tickets to events.
151
Let's look at another example.
152
Consider Tinder.
153
Tinder is a similar case where we need consistency for matching
154
because if user A swiped on me in Europe and then I swipe on them in the United States, I want to immediately show the user a match.
155
You matched right when you swipe if you're the second person swiping.
156
And so I need a consistent view of who swiped of me.
157
Cool.
158
So consistency for matching.
159
But when it comes to viewing profile data, again, if a user went and updated their profile to a different picture or something like this, it's okay if I see the old picture for a while,
160
a couple seconds, minutes, so be it.
161
And so in Tinder, I would say to my interviewer, I'm going to prioritize availability for viewing profile data and updating profile data, but I'm going to prioritize consistency for match data.
162
Now, there's one other thing in this so-called advanced section that's relevant.
163
You'll hear consistency always used and people will just say consistency in the context of cap theorem.
164
What they really mean is strong consistency.
165
They mean all reads reflect that most recent right.
166
This is what we've been talking about.
167
So if you hear consistency in this context, just think strong consistency.
168
But the reality is there's different levels to consistency.
169
And if you want to be fancy, you can get into the nuance of these different levels in your system.
170
And so there's also what's called causal consistency.
171
And this just ensures that related events appear in the same order.
172
And so for example, you can't have a comment on a post, maybe replying to a previous comment, right, that comes before that comment it's replying to.
173
That wouldn't make sense.
174
So it's okay if these things take a while to come in and not everyone sees all the same comments,
175
but nobody should see a comment replying to a previous comment in the inverted order.
176
Hopefully that makes sense.
177
A third one here is read your own writes consistency.
178
And so this is that I as a user should have a consistent view of what I've just done, but other users could see something different.
179
And so back to our USA Europe example, user A who updated their profile should immediately see their own profile update, or else they'll think the system was broken.
180
So they need read your rights consistency, but the system doesn't need strong consistency because user B in Europe can still see the old thing.
181
That's fine.
182
And then of course, as I've been alluding to throughout this whole interview, the lowest level of consistency is that eventual consistency.
183
So when we choose availability over consistency, we're not saying our system's not gonna be consistent.
184
We're just saying that we're okay with eventual consistency.
185
We're okay that it's gonna take a while for the system to level out into a consistent state.
186
So if you wanna go into each of these in your interview, it can show some nuance, it can show some senior, some staff level thinking when you be specific here.
187
All right, folks, thanks for watching.
188
Hopefully this was useful.
189
let me know in the comments what you think of this new format.
190
It ended up being longer than I thought it would be.
191
I thought this would be five minutes, but, you know, let me know.
192
I want to hop in here and maybe make some of these periodically
193
when I learn that something is a little bit more confusing to folks.
194
As always, we got a bunch of great breakdowns on the website, hellointerview.com, a bunch more deep dives on content just like this.
195
Check it out.
196
And then actually at the end of this month, November 2024, I don't know when you're watching this, we're going to be launching a bunch more contents, kind of in a premium offering.
197
so people are always asking for more content the free content will always continue the youtube will continue
198
but we will have even more content for those who want to pay for premium
199
so keep an eye on an eye out for
200
that it'll be coming at the end of the month awesome all right folks good luck with your interviews
ऐप डाउनलोड करें
Everything you need to speak fluently
AI PronunciationScore every sentence
IPA PracticeMaster every sound
VocabularyBuild your word bank
Vocab GameLearn while playing
इस पाठ के बारे में
आप "CAP Theorem in System Design Interviews" के साथ Shadowing तकनीक का उपयोग करके अपनी अंग्रेजी का अभ्यास कर रहे हैं।
शैडोइंग तकनीक क्या है?
शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।