YT YouTube2Text

YouTube2Text → Transcripts → Essential System Design Concepts You Should Know - System Design Tutorial

Essential System Design Concepts You Should Know - System Design Tutorial — Transcript

by Caleb Curry · 7,752 words · 1,126 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00welcome back to your system design
0:02Series this video we're actually going
0:04to talk about some of the most important
0:05terminology you should be familiar with
0:08as you start studying the rest of these
0:09lessons now one of the first things I
0:11want to talk about is scaling an app
0:13from just a few users to potentially
0:15millions of users and we're probably
0:17going to start that process in the next
0:19lesson because I want to get some
0:21foundational stuff of system design out
0:24in this lesson so this will basically be
0:25a very brief intro to a bunch of
0:27different topics and keywords you should
0:29be amiliar with but you don't need to
0:31understand them at a very intimate level
0:33this is really just so when you see
0:35these words in the future lessons you
0:37have an idea of what that means and it's
0:39not completely brand new to you so
0:41really this is just designed to give you
0:43that thousand foot view of everything
0:44we're going to be talking about but you
0:46don't have to leave this video knowing
0:48every single word in a lot of depth now
0:51I just wanted to first show you this
0:52beautiful system design that my wife
0:55wrote up here this was for the previous
0:57video's thumbnail but we're not going to
0:58leave that up so I'll just do ER that
1:00real
1:01quick oh
1:04snap oh no before we get started I
1:07wanted to share two Resources with you
1:09the first is a back-end software
1:11engineering mind map this is going to
1:13share with you every technology you
1:14should know if you want to become a
1:16backend software engineer the second
1:18thing is if you need help applying the
1:19principles that we teach here as well as
1:21the things on the Mind map then I have a
1:23mentorship program this is where you can
1:25get one-on-one help to learn the skills
1:27to become a software engineer and get a
1:30high paying software engineering role so
1:32if that's something you'd be interested
1:33in I'll have a link for that as well as
1:35the Mind map down below so the first
1:37word I want to talk about is distributed
1:39systems or distributed computing the
1:42idea of something being distributed is
1:44running it across multiple
1:47computers so we'll just say distributed
1:50computing and these are pretty general
1:53terms so we're not referring
1:55specifically to the backend or the
1:58databases but pretty much anything could
2:00be ran in a distributed environment we
2:03will get into some Concepts that apply
2:06to specific sections of our application
2:08such as the database level but now we're
2:10just thinking pretty General anytime we
2:12want to run an application but it's
2:15distributed across multiple computers
2:18we're working with distributed computing
2:20pretty sure I just Ed the word in the
2:22definition but the idea is instead of
2:24running your service on a single
2:27computer you might run this on multiple
2:30computers and all three of these in this
2:32case have to work together to give a
2:36single result so we have to start
2:38talking about ways to get multiple
2:40computers to work together so that we
2:43end up with just a single result so this
2:46is going to introduce a lot of
2:47challenges many of which we'll talk
2:50about in this series so a lot of the
2:52next words that we're going to talk
2:53about build on the idea of distributed
2:56computing the first one I want to talk
2:58about is availability so in the
3:00situation of what we just had where we
3:02had three computers working
3:06together this is likely a highly
3:08available system if one of the computers
3:11goes out the other two servers will
3:14compensate taking the load that was
3:17originally given to this computer so if
3:20we put a circle around this to basically
3:23say hey this is one unit and somebody
3:27makes a request to the service this
3:30request could go to any of these
3:32notes and if we structure it to be
3:36highly available if for some reason this
3:38node is down the request would not go to
3:41that node it would just be redirected to
3:43one of the other nodes so that's the
3:46idea of availability our goal is to be
3:49available 24/7 this is impossible so we
3:52want to get as close as possible to this
3:54and we'll talk about that now now
3:56because it is impossible to have a
3:57service that runs 24/7 guarant aned
4:00there are different levels of how
4:02available a service should be and these
4:04are measured in nines so one nine would
4:07be 90% of the time which means in one
4:11year the service could be down 36 and 1
4:1412 days which is 10% of a year so
4:1936.5 days of potential downtime now it
4:22doesn't necessarily mean the service
4:24always is down 36 days out of the Year
4:26this will be a worst case scenario if a
4:28service said that they were guaranteed
4:30to be up at least 90% of the time then
4:33we would have two NES which would be 99%
4:36we're getting a little bit better and
4:38while that might sound nice like hey
4:39it's up 99% of the time still pretty bad
4:42because this would be 3.65
4:46days so that's 2 9 if you go to Three N
4:49it would be 99.9 4 9 would be
4:5399.99 and you can keep adding nines to
4:56get as close as possible to 100% of the
4:59time every time you add a nine to your
5:00service it becomes more difficult but
5:03low numbers like these are super easy to
5:05achieve when you start getting to five
5:07six in a higher number of nines it's
5:08going to become more challenging but if
5:10you have a service that goes down almost
5:124 days once a year that's pretty
5:14terrible at minimum if you're looking
5:16for just a ballpark shoot for 49 this
5:19translates to less than an hour of
5:22downtime per
5:25year which for some things that's not
5:28going to work you know if you're working
5:30on some medical system or some Financial
5:32system or military system an hour of
5:36downtime could be pretty bad but in many
5:39apps if an app goes down a couple of
5:42minutes here and there and over the
5:44course of a year it's less than an hour
5:46that's pretty good for many apps so this
5:48would be a benchmark and if you need it
5:50a little bit more serious then just add
5:52additional nines and start looking for
5:54ways to achieve that we'll get into some
5:56of the ways you can increase the number
5:57of nines for your services so if you
6:00don't feel like this is adequate we're
6:03going to talk about ways you can achieve
6:05more than that but this is just a
6:07starting point to summarize that as the
6:09number of nines go up so does the
6:12availability which I'm just going to
6:14write ha for high availability however
6:17the costs are going to exponentially
6:19increase as well as the general
6:22challenge of
6:23implementing
6:25the service so more cost and more
6:28challenge especially something to
6:30consider if you're hiring developers
6:32they're going to cost money so not only
6:36will the services you pay for such as
6:39database hosting and servers go up in
6:42cost but the actual skills required to
6:44implement things and keep everything
6:46running is going to go up as well and
6:48that ultimately could come back to cost
6:50next up we have reliability and this is
6:53a service's ability to do what it is
6:55supposed to do so you can imagine you
6:58have a service that's up
7:0199.999% of the time but the service is
7:04nonfunctional or it's doing something
7:06incorrect such as doing some database
7:08stuff where data is being lost this
7:11would be a problem with
7:14reliability and this is a little bit
7:16more abstract or hard to measure and
7:19when you're defining what reliability
7:21looks like in your app you can define
7:23those rules so it's not something where
7:26it's just hey here's a certain number of
7:28nines it's more abstract you have to
7:30think about what the application should
7:32be doing and what success looks like and
7:34what failure looks like but this is a
7:36general term to refer to the ability for
7:38an app to do what it is supposed to do
7:41so does the app actually work even if
7:44you have let's
7:49say 6 9 of uptime you might have z%
7:54reliability this setup is kind of like
7:56if you have a friend who's always
7:58available you can call them text them
8:00they'll answer always get back and
8:02they'll help you with anything but when
8:04you actually need them to come over to
8:05help you move they don't show up or they
8:08show up and they're totally useless
8:10they're always available but they're not
8:12reliable two different concepts so just
8:14to kind of get that straighten away in
8:16your mind availability is about the
8:17ability to access a service the
8:19reliability is about is the service
8:22functional the way it should be
8:23functioning next big word you should be
8:25familiar with is consistency so this has
8:28to do with every everybody seeing the
8:31same data at the same
8:34time this is really only going to be a
8:36concern when you start working in
8:38distributed systems if you have one
8:41computer one server that's serving your
8:43application you are always 100%
8:46consistent because the definition of
8:49consistency is everyone sees the same
8:52data at the same time so everyone here
8:55is probably going to refer to the
8:57clients trying to access This Server so
9:00if you have a web server this could be
9:03the backend API and people are trying to
9:05retrieve data through some frontend
9:08application so we'll get into more of
9:10all of that architecture throughout this
9:12series but for our little example here
9:15we can imagine we have two people and
9:18they're both on their
9:21computers dang that is a really good
9:23looking
9:24computer that one not so much but we
9:26still love you and because both of these
9:29clients
9:30are retrieving data from the same Source
9:32they're going to see the same exact
9:34thing they are 100% in sync they are
9:37consistent there's also a term eventual
9:39consistency which we're going to get to
9:41in a second but let's just go with this
9:43for a second you're either going to be
9:45consistent or not consistent so let's go
9:47through the scenario where now instead
9:49of having just a single server you have
9:51two or three or more servers so now we
9:53have a scenario where we have three
9:56servers you could imagine these being
9:58database servers where these are storing
10:00data and each one of our clients access
10:04a different server the question of
10:06consistency is if all of these users are
10:09requesting the same piece of information
10:11let's say the user with the ID of five
10:14are they going to get the same result
10:16there's a scenario where they might not
10:18and that is if instead of just reading
10:21the data from one of these clients we
10:23actually updated it so let's say we
10:25changed the user's name from John to
10:29Caleb if our service is not consistent
10:32and these clients request that user
10:35information they might get the outdated
10:37information so this change would
10:39eventually propagate to this server and
10:42this one too but that takes a little bit
10:44of time right it takes time to copy that
10:46data over so if we make these requests
10:49at the perfect time right before that
10:52data is copied over we might get
10:54inconsistent results so let's go through
10:56the scenario we updated from John to
10:58Caleb So This Server is going to see
11:01Caleb because that data is in that
11:05server and then let's say that change
11:06propagates to This Server so when this
11:08computer tries to retrieve that user
11:10information it will also get
11:13Caleb so far so
11:16good however this one it didn't quite
11:20copy that data over in time and the
11:22request retrieves old data that hasn't
11:25been updated yet so this one's going to
11:27retrieve JN which is not correct the
11:31results are inconsistent I know I'm
11:33probably drilling this idea into your
11:35head a little too much but just
11:38understand when people say consistency
11:40it truly means are you getting
11:42consistent results across the server in
11:45this scenario you're getting
11:47John Caleb and Caleb so with this
11:51scenario if you were asked is this
11:53database setup consistent the answer
11:56would be no not consistent
12:02however when I'm saying consistent here
12:04I'm specifically referring to strong
12:07consistency so that's another word you
12:09should be familiar with and strong
12:11consistency means when there's a right
12:13that happens or some kind of change that
12:14change is going to be available
12:16immediately on all of the nodes there's
12:18another type which is eventual
12:20consistency and that is basically when
12:22there is a change eventually that'll be
12:25copied over to the other nodes it's just
12:27not immediate so let's erase this and
12:29then talk a little bit more in detail
12:31about the differences between strong
12:32consistency and eventual consistency and
12:35which one is correct or which one you
12:36should use or what you'll typically see
12:39so if we have a distributed system that
12:42is strongly consistent the way this is
12:44going to work is it's going to wait to
12:47confirm the change until all of the
12:50other nodes can also apply that change
12:54so just to save space here I'm going to
12:55draw those three nodes in a line here so
12:58we can have some more room to write and
13:00we make some change to the data on this
13:03node that change will be in a pending
13:05State it's not confirmed yet until that
13:08change is propagated to the other nodes
13:11and they have that change locally and
13:14they can all be applied so that the
13:17change is confirmed so in this situation
13:19you're not going to see any
13:20inconsistency because the change is
13:22applied to all of the nodes at the same
13:24time the major downside to this is it's
13:27going to take time we now now have to
13:29wait for that change to propagate to
13:32these other nodes before we can see that
13:34change confirmed on the main node we're
13:36working with the major benefit is
13:39consistency the other type of
13:41consistency we're going to talk about is
13:43eventual consistency which in my book
13:45would be not consistent but it's still a
13:49form of consistency because the other
13:51nodes will eventually get the data it's
13:53just not going to be immediate so with
13:55the eventual consistency we're going to
13:57have the same setup let's go with three
13:59nodes
14:01here and we make some change to a node
14:05so we update some data this will be
14:07immediately confirmed and then
14:10eventually that change will propagate to
14:12the other notes so there's a scenario if
14:15you access the data immediately after
14:17it's written to the right node that will
14:21get some inconsistent State and we're
14:23accessing stale
14:26data and this would only happen if you
14:29manage to access that data before that
14:32propagation happens from the main node
14:35can't really erase that blue too well so
14:37we could say it propagates to this one
14:39but it's not quite done propagating to
14:41this other node so when we access the
14:44data we get stale data so one client
14:47might receive something different than
14:49another client the person accessing this
14:51node will get the update data the person
14:54accessing this node since the
14:55propagation has completed will get the
14:57up toate data but the person accessing
14:59this node will get stale data the old
15:02data before it was updated so the major
15:04downside here is that the data is not
15:08consistent which means it's kind of not
15:10trustable the major benefit and I'm
15:12drawing a down arrow so don't be
15:14confused because we are going to reduce
15:17the time to write data we can write data
15:20and we don't have to wait for that to be
15:22confirmed on the other nodes before we
15:24can confirm the entire transaction so
15:27it's not a question of which one's right
15:29it's a question of which tradeoff do you
15:31prefer in an environment that's strongly
15:33consistent you're going to have
15:35consistent data across all the nodes but
15:38it's going to take a little bit more
15:39time to write data to the database in an
15:42eventual consistency environment you're
15:44not going to have that consistency right
15:46away but the time to write is going to
15:49be much faster which approach you take
15:51depends on the application so I'll write
15:53some scenarios where you might choose
15:55one over the other so a big one is going
15:58to be banking
16:01you can imagine a scenario where you
16:03transfer $100 is the last $100 you have
16:06and now your account says zero like
16:08usual the problem here is that someone
16:11could access your data on another node
16:13and still see that you have $100 and
16:15then make another transfer or that
16:17difference might make the difference
16:18between getting approved for a loan or
16:20not getting approved for a loan so
16:22anything dealing with money should be
16:23consistent other examples would be
16:26potentially medical stuff especially if
16:28it's real
16:29Time stuff that's like electronic health
16:32records probably not a big deal to be
16:34strongly consistent because that data
16:36doesn't change very often so it's really
16:38about reading old data consistency is
16:40really important when we're talking
16:42about new data being added or data being
16:44modified another example might be
16:47military you definitely don't want to
16:49have inconsistent State when you're
16:50trying to decide if you know you should
16:52fire a weapon like that's something
16:54where you want things to be consistent
16:56there is another big issue here which
16:58has to do with availability and the cap
17:00theorem which we're going to get into
17:02but basically one of the downsides of
17:04strong consistency is that it can harm
17:06your availability so we're going to get
17:08into that but this scenario would be if
17:11you have a medical scenario or a
17:14military scenario where differences in
17:17data could be detrimental so I'm going
17:19to write these in parentheses saying
17:21maybe just depending on the use case but
17:24definitely probably want to keep strong
17:26consistency with anything Financial
17:29so let's talk about eventual consistency
17:31some examples of when you might prefer
17:33this route would be social media or
17:36other basic crud apps create read update
17:39delete basically websites or apps where
17:42you're changing some data you know you
17:44might post a status but if that doesn't
17:46show up for people for a couple of
17:47seconds it's really not that big of a
17:49deal you're not doing any real-time
17:50trading or anything like that so it's
17:52not the end of the world if you get some
17:53stale data especially if it's only stale
17:56for a brief period of time next up we're
17:58going to talk about scalability and
18:00honestly of all the words if if you're
18:03talking to somebody in
18:05marketing or you know the CEO as long as
18:08your app is scalable that's all that
18:10matters so you can ignore all the other
18:12stuff so it's a buzzword but there's a
18:14lot more to it what does it mean if an
18:16app is scalable the summary is that your
18:18app is able to support an increase in
18:22the workload which could come from a
18:24spike in traffic or particular parts of
18:27the year maybe Black Friday you need
18:29more computing power so you can support
18:32the new users one of the easiest ways to
18:35achieve scalability is with over
18:37provisioning so if you imagine this
18:39being your server that runs your
18:42application and we're not going to get
18:44into splitting out the database and the
18:46backend API let's just keep it General
18:48here this is our application and inside
18:52of the server you have a certain amount
18:53of computing power CPU RAM and even
18:57storage whether that's hard disks or
19:00ssds and let's say the utilization of
19:03the server is down here so you're really
19:06not using all of your computing power
19:08maybe 20% so that's okay and you know
19:11you could probably go a little higher or
19:12a little higher but as you start to get
19:15to using the majority of your Computing
19:18resources now you're going to start
19:19having issues and I'm going to say that
19:21that's bad so you want to have a little
19:23bit of space between how much Computing
19:26you need which in this case what we
19:28wrote was is right here this is what we
19:30need and the max you could support so
19:34from day to day you don't want to be
19:35capped out but also consider the cases
19:38where you might have spikes perhaps it's
19:40a certain time of day every day at 8:00
19:43a.m. you have more traffic so you want
19:46to consider not only the typical usage
19:49but also what might be the most usage
19:52that you need so this is just a visual
19:54to show how much computing power you
19:55might need compared to how much you have
19:58available you might only be using half
20:00of the available processing power for
20:03example if the amount of compute you
20:05need for Peak usage is well within the
20:08max then you have a scalable service
20:10because even in the worst case scenario
20:12where you hit that Peak usage you still
20:14have all of this space and you want to
20:16avoid getting into the areas where
20:18you're almost maxing out the computer so
20:21let's say there are scenarios where
20:23typical usage is well within the realm
20:26of this computer but there are certain
20:28times maybe once a year or once a
20:30quarter where you need even more than
20:33what's allowed in this server you're
20:35going to have to do something else to
20:37scale this app so there are a few
20:39different approaches to scalability
20:42Beyond just overr provisioning having
20:45some massive server and just hoping you
20:47never reach the max what if you do reach
20:49the max what do you do there's a couple
20:52of different approaches we're going to
20:53talk about the first one being vertical
20:56scaling and the second one being
20:57horizontal scal scaling vertical scaling
21:00the idea is simple we just add more
21:02Computing resources practically that
21:04means if this was your previous server
21:07you can
21:08upgrade getting a new server or adding
21:11more processing power more RAM but we
21:14still go from one server to one server
21:18it's just a stronger server this is
21:21often also called scaling
21:24up we're just increasing the Computing
21:27resources but we're still within a
21:29single server horizontal scaling on the
21:31other hand is actually adding servers so
21:34instead of just having this little
21:36server you could have multiple of these
21:39little servers working in unison or you
21:42could do a combination of both but just
21:45to finish this real quick this would be
21:47scaling
21:49out the combination would basically be
21:52not only adding servers but also
21:54increasing the computing power so that
21:56might be going from this to
21:59now having even bigger servers so it
22:01might look something like that so a
22:03single server may not have been able to
22:05scale enough and even increasing some of
22:08the computing power might introduce
22:11limitations if you're at a really large
22:13scale so you can go from one server to
22:17two or more servers and now you should
22:19be able to maintain enough computing
22:22power to handle all of the requests so
22:25this might happen say once a year the
22:27actual frequency would vary completely
22:29based on what kind of app you're
22:31building but the challenge is you
22:34probably don't need Max scaling all the
22:37time because applications often grow and
22:41decrease in their usage for various
22:43times of the day or various times of the
22:45year so a very similar word but a little
22:48bit different more focused on the
22:49ability to grow and Shrink is elasticity
22:52so with scalability when there's an
22:54increase in the workload we just
22:56increase the compute
22:59so it looks like
23:01this however this may require manual
23:04intervention and it's typically more
23:06worried about the increase in workload
23:09whereas elasticity deals with an
23:12increase in workload and then eventually
23:15a decrease in workload when the workload
23:18is higher we will increase the computing
23:21power and then when the load is lower we
23:25will decrease the computing power
23:30so elasticity is the ability for an app
23:33to automatically adjust based on Usage
23:37Now that might be confusing like how
23:39could you just always be adding hardware
23:42and removing hardware and typically it's
23:45going to be done by some cloud provider
23:48so when you're looking at Cloud
23:49providers to host applications you can
23:51check to see if the service is elastic
23:53and it will do the growth and decrease
23:56behind the scenes for you and because
23:58these applications are often virtualized
24:00they might not actually be adding a
24:03processor to your computer and then
24:05removing a processor they just have a
24:07bunch of servers that will run all of
24:10the applications and then allocating
24:12more or less resources for any
24:14particular application so that's how a
24:17cloud provider can easily allow for
24:19elasticity without technicians being in
24:21there manually adding and removing
24:23Hardware all of the time so these words
24:25are very similar and you might hear them
24:27used interchange but if we're going to
24:29try to be as clear as possible I would
24:31say scalability is focusing on having
24:33enough computing power for an increased
24:35workload without having your application
24:38shut down or you know just completely
24:40break this can be achieved various ways
24:42whether that's manual intervention or
24:43some automatic setup even if it's just
24:45over provisioning and having more
24:47Hardware than you really need one step
24:49further would be elasticity where the
24:51compute is automatically adjusted either
24:53up or down based on the current workload
24:56now just to review and make sure we're
24:58all on the same page the scalability
25:00does not refer to a Services
25:03availability you could have one server
25:06that you just increase the amount of
25:08computing power it has to increase the
25:10scalability but that doesn't necessarily
25:12mean it's highly available because you
25:14could still have one server and if that
25:16server breaks well your entire service
25:19goes down doesn't matter if you have the
25:21most powerful computer in the entire
25:24world if it goes down for some reason
25:27you're still kind of screwed because you
25:29don't have any backup computers so that
25:31idea is known as a single point of
25:33failure so a single point of failure you
25:35can think of it as any Link in a chain
25:38that does not have any kind of high
25:40availability or redundancy so that's
25:43another word we're going to write down
25:45here so redundancy is just having an
25:47extra there in case something goes wrong
25:49with the main one kind of how you would
25:51have a spare tire with your car if you
25:53have a flat you can swap out one of your
25:56wheels with the spare and you can still
25:58function it's often the case that in
26:00real life people think of redundancy as
26:03a bad thing if something's redundant we
26:05don't need it so get rid of it however
26:08in Computing It's usually the opposite
26:10we want redundancy so redundancy is
26:13usually a good thing a single point of
26:15failure is usually a bad thing so we're
26:19going to make sure this is really clear
26:21drawing these faces redundancy it can
26:24add cost but it can make sure a service
26:27stays available consider the case where
26:29we have some database server and let's
26:31say we're connecting to this from some
26:33Advanced backend which has load
26:35balancing and a bunch of servers so this
26:38is great there's no single point of
26:40failure here and then we're connecting
26:42to it from some Advanced front end as
26:45well so checking if these have
26:46redundancy let's say the front end does
26:48have redundancy the back end has
26:50redundancy but we get to the database
26:53layer and it does not have redundancy
26:56this would be our single point of
26:57failure and when we're trying to build
26:59highly available systems our job is to
27:01identify single points of failure and
27:03try to remove them with various
27:05approaches the usual First Step would be
27:07to add redundancy so if we add in a
27:10standin server which is just going to
27:12act as a replacement if the main server
27:15fails for some reason you can imagine
27:18this server explodes the data center
27:21disappears something terrible happens
27:24well this server is ready to go has all
27:26of the data the same as this server it's
27:29consistent with the main database this
27:32would immediately be promoted and our
27:35traffic would route to that new database
27:38instance this standin is a little bit
27:41different than the back end where we
27:43might have multiple servers all sharing
27:45the load the standin in this scenario
27:48does not take any of the traffic
27:50typically it just acts as an emergency
27:52fill in if something goes wrong with the
27:55primary database so that is an example
27:57of redundancy anytime we add redundancy
28:00we're probably going to add cost because
28:03we now have to maintain two database
28:06instances another important word you
28:08should know is Fault tolerant or fault
28:11tolerance so we created a fault tolerant
28:14system A system that will still function
28:17if something goes wrong by removing
28:20single points of failures and we remove
28:22the single point of failure by using
28:24redundancy having a standin database in
28:26case something goes wrong so fault
28:28tolerance that's a general term to
28:30describe what we did we created a system
28:33that is tolerant to faults by adding in
28:37new things such as redundant servers so
28:40by removing single points of failures we
28:43can achieve fault tolerance and we do
28:47that through adding redundancy the
28:49specific thing we did to introduce
28:52redundancy in our application is
28:54database replication so we pretty much
28:57just created a replica
28:58from the primary node to the secondary
29:01node which that's another word we've
29:03been throwing around but the term node
29:05just means one of the computers in a
29:08multicomputer setup where a computer is
29:12a server so a node is a server which you
29:16can just kind of think of as a computer
29:17designed to run something such as a
29:20database for some of you who've worked
29:21with databases and servers before that
29:23might be super obvious but if you're
29:25just a beginner getting started people
29:27throw a lot of these words out without
29:29really describing what exactly they mean
29:31so a node would just be one of these or
29:35this would be another node and the idea
29:37of replication is creating a duplicate
29:40node let's zoom in a little bit more on
29:43databases and talk about some terms with
29:45that so when we're working with the
29:47database and we get to the point of not
29:49just having a single instance or a node
29:52and we actually want multiple nodes
29:54might look something like this you could
29:56call this entire thing
29:59a database cluster now when you're
30:01talking about databases and database
30:03clusters there are various setups you'll
30:05see so this isn't going to be the only
30:08way you will see it but a very common
30:10scenario is you'll just have one master
30:14node and then the rest being slave nodes
30:18or you could just say that this is a
30:20right
30:23node and these are read nodes so we kind
30:26of showed this already earlier where you
30:28write to a node and then that data is
30:32given to the other nodes in the system
30:35so you can think of both of these as
30:41replicas and then it's just a matter of
30:43do we want these to be strongly
30:46consistent or eventually consistent so
30:48we already understand the idea of
30:51consistency and we already talked about
30:53how if something is consistent it takes
30:55more time to make that right but to get
30:57a little bit more technical on the
30:59terminology when we make these replicas
31:02the act of replicating replication has
31:06two different approaches which would be
31:09synchronous which would be
31:13consistent and what this will do is it
31:16will replicate the data over and it will
31:19do it synchronously waiting for the
31:22result so all of the nodes have to write
31:26the data in order for for the data to be
31:29confirmed so nothing different than what
31:31we've already talked about with
31:33consistency it's just you might also
31:35hear the term synchronous replication
31:38comparing that to
31:40asynchronous which will basically just
31:42send data over as it gets
31:46it not really worried about the time it
31:49takes for that data to be confirmed on
31:52the replicas so this node can still be
31:55doing things while these other nodes are
31:58writing that data and that's the whole
32:00idea of it being asynchronous so that is
32:03eventually consistent now the change in
32:05time that synchronous replication is
32:07going to cause is called
32:11latency so latency is just a measure of
32:15how long something takes from request to
32:18response so say this is me and if we're
32:20just talking about General latency here
32:22I make a request to a web page and that
32:25web page shows up after say 100
32:28[Music]
32:30milliseconds this is the idea of latency
32:34but you could obviously split that out
32:36at different levels so we could talk
32:37about latency at the database level and
32:40when things are consistent the latency
32:42is going to go up so just another word
32:45you should be familiar with it's going
32:46to worsen the overall user experience
32:48because the time from request to
32:50response is longer now in this scenario
32:53we just have one primary node and then
32:57two re read replicas when we're getting
33:00deeper into database clustering it could
33:01be the case that we have multiple write
33:04nodes so what if we not only wrote to
33:09this node but we could also write to
33:11this node that's going to introduce more
33:13interesting challenges and while I think
33:15this is important to understand the
33:18first step in terms of growing your app
33:20for scalability and availability would
33:23be to introduce reading nodes and just
33:25directing read traffic to the read nodes
33:28and right traffic to the right node
33:30however if we want a multimaster setup
33:32then we have to talk about more advanced
33:33database clustering techniques which is
33:36probably something we're going to get
33:37into in more detail later on in this
33:39series so for now for our basic example
33:42just imagine there being a single write
33:45node and then multiple read replicas
33:49that's usually pretty good because it's
33:51often the case that applications will be
33:53more read heavy and not write heavy so
33:57you might read 80% of the time and write
33:5920% of the time so you can have more
34:03read replicas and individually scale
34:06these keeping just a single right node
34:10and then when it comes to redundancy you
34:12can have a backup write
34:14node that's not actively used for
34:17writing but acts as a standin if for
34:20some reason our right node goes down we
34:23can direct traffic to the standin node
34:26but they're not both being used used for
34:28writing at the same time which
34:29introduces various other challenges so
34:32if you don't have multiple write nodes
34:34the structure is pretty simple even
34:36though I drew a bunch of complex lines
34:38and circles here the general idea is you
34:41just have a right node possibly a
34:43standin node for redundancy and then
34:45you'll have read replicas which are
34:48either consistent or eventually
34:50consistent we have talked about a lot
34:53and a lot of database stuff as well
34:55we're going to do a little bit more
34:56about databases but this time we're not
34:58going to talk about databases with
35:00replication in a distributed environment
35:03instead we're going to talk about just a
35:04single database instance because even on
35:07a single computer there are certain
35:08rules we want to enforce to make sure
35:10our database is usable and trustworthy
35:13so you may have heard of the term acid
35:16uh not like the stuff that like melts
35:20stuff or like the drugs but acid in
35:22databases so you may have heard of
35:25databases being acid compliant and what
35:28in the world does that mean that's what
35:30we're going to talk about this is an
35:31acronym for four different properties of
35:34databases now this is what most
35:36databases are going to strive for and
35:38most relational databases are going to
35:40be acid compliant there are certain
35:43databases out there that do not meet all
35:45of these expectations for various
35:47reasons but this is a general starting
35:49point so if you're working with a
35:50typical SQL database such as postgress
35:53this is going to be an acid compliant
35:55database so we're going to go over these
35:57very briefly and we may do a dedicated
35:59video to this topic just depending on
36:01how much information I want to cover on
36:04these things but I just think it's a
36:05good idea to know that they exist and be
36:07lightly familiar with what they are so
36:10atomicity believe that's how it's
36:12pronounced basically the idea of
36:14something being a single unit you can
36:16think of an atom even though you can
36:17split atoms a good example of this would
36:20be if you run a transaction the
36:23transaction will either succeed or it
36:25will fail it's one unit you can't have a
36:27partial completions so transactions will
36:30either succeed or they will fail
36:33consistency this can be a bit confusing
36:35because we've been talking about
36:36consistency this entire video but this
36:38consistency is actually referring to a
36:40different kind of consistency so why
36:42they're not consistent with the usage of
36:44the term consistent is beyond me but the
36:48consistency here is referring about
36:50State changes in the database so when
36:52you do some processing your database
36:54starts in one state and will move to
36:58another valid state so this is a valid
37:00State and this is a valid State meaning
37:03any change is required to adhere to any
37:06kind of Integrity rules you set at the
37:08database level so we haven't gotten into
37:10a ton of the details of databases in
37:13this series yet but an example would be
37:15referential Integrity so I'll just write
37:17up here respecting foreign keys so you
37:21can't create a change in the database
37:22that breaks some defined rules that you
37:24created for the database this helps your
37:27data have integrity which means it's
37:29correct and trustworthy isolation you
37:32can think of individual transactions as
37:35being isolated not dependent on other
37:38transactions that might be happening
37:40concurrently so I just put independent
37:43execution I was trying to think of a way
37:44to describe it without using isolation
37:46in the definition this would be kind of
37:48cool one to go into in more detail
37:50because that's pretty vague so you can
37:53look into concurrency stuff with
37:55whatever database you are using and then
37:57durability is basically data
38:00permanence once the data is committed or
38:03saved it's permanently saved even if
38:05there was a power outage right after
38:08that saving is a checkpoint and you
38:11wouldn't ever expect to have your system
38:13go back to before that committed data so
38:16you can trust changes to persist in an
38:19acid compliant database another database
38:22word I want to talk about is
38:25sharding and this is a specific type of
38:28database
38:29partitioning so two words we need to
38:31talk about real
38:35quick so database partitioning can
38:38happen at the individual database level
38:41or within a larger database cluster So
38:44within an individual database let's just
38:45say we have one database server you
38:47might have some massive table this table
38:50might be massive because it has a lot of
38:53columns so you can imagine it being
38:55split up a lot this way
38:58and one individual row might have a ton
39:00of data because has data for all of
39:02those columns so you could optimize
39:05performance with this table by splitting
39:07up the table into multiple tables
39:10typically you're not going to have to do
39:11this unless you're really working with
39:13big data but it would look like this you
39:15split it and now we might have a table
39:17with this section and a table with this
39:20section and then you can just connect
39:21rows with the foreign key so this would
39:23be vertical partitioning
39:27horizontal partitioning works pretty
39:30similar but instead of splitting by
39:32column we'll split the data so you can
39:35imagine if you had a bunch of rows you
39:37can split the data so that the rows are
39:40split up instead of the columns so for
39:42example this row might be assigned one
39:45this one might be assigned two and then
39:47this one might be assigned three and
39:49then again one and then
39:53two and so forth where now if we wanted
39:57to to just access a certain subset of
40:00this data such as anyone from partition
40:04one we would only be working with two
40:06rows instead of the entire data set so
40:09you can imagine the ones twos and threes
40:11being split up across different tables
40:14kind of and then it's just a matter of
40:16knowing which table to access to get the
40:18correct information so again we're just
40:21going very surface level we'll get into
40:23partitioning in a lot of detail so don't
40:25feel like you have to understand all of
40:26it in this video video the general idea
40:29is we can reduce the row count by just
40:32working with a subset of the rows in
40:34this case just my madeup example of
40:37labeling them one two or three so that
40:41is an example of
40:44horizontal
40:46partitioning so this can all be done
40:48within the same database instance So
40:51within postgress for example you could
40:53just split up your table into two
40:55different tables with a subset of
40:57columns or postrest supports horizontal
41:00partitioning so it can basically do this
41:03for you and then give you like a virtual
41:05table to see all of the data whereas
41:08creating the virtual table to see all of
41:10the data over here would be to create a
41:12view so again we're getting into the
41:15details but basically partitioning can
41:18be done at just an individual database
41:20level without having to worry about
41:23replication or distributed computing
41:26however if you want to take this idea
41:27and go one step further across different
41:31nodes that is what sharding is you might
41:34be able to use those terms
41:35interchangeably but typically when
41:38people are talking about sharding it's
41:39because they want to split the data up
41:42across nodes so then instead of just
41:45having replicas for fault tolerance and
41:48potentially independently scaling the
41:51reads and writes now you could actually
41:53split the data across multiple nodes and
41:56only have for example in this case a
41:59third of the data to deal with so you
42:02could imagine assigning each one of
42:03these to its own database node so that
42:06is a very high level of what sharding is
42:09and how it works but there's a lot to it
42:11and we'll get into you know how do we
42:13decide how to split up this data how's
42:15that work inside of a database cluster
42:18because it's not always the case that
42:19the database cluster will have complete
42:21notes sometimes they will just have a
42:23subset of the data because they're using
42:25sharding
42:27and I'm saying sharding not sharting by
42:29the way wow we went through a lot of
42:32material introducing many different
42:34topics my goal here was to give you like
42:37the intro to each major topic so now you
42:39have a better idea of what we're going
42:41to conquer in Greater detail in the
42:42upcoming lessons so the takeaways from
42:44this video Dang applications can be
42:46pretty complex behind the scenes there's
42:48actually a whole other world that I
42:50didn't introduce which is caching that's
42:52something we're going to do dedicated
42:54videos on so we're not going to get into
42:56it much detail here the main thing you
42:59need to know about caching is it's a way
43:01that you can temporarily store data for
43:04easy fast access to reduce the
43:06computation needed on the API or the
43:10database layer so if we can remove a
43:12substantial number of requests that need
43:14to be made to the database we probably
43:16don't have to worry about all of this
43:18crazy database setup stuff nearly as
43:21soon the main thing you would just want
43:23to do is have the availability by having
43:25that standin node and and then just
43:27scale your node vertically not having to
43:30worry about complex clustering setups
43:33another takeaway from this that you will
43:35benefit from which we didn't get into a
43:37lot but there's various cloud services
43:39you can use that will often abstract
43:42away a lot of this for you so for
43:44example you might be using a cloud
43:46database and that cloud database might
43:48be
43:49serverless and this doesn't mean that
43:51there is no servers being used for the
43:54database it just means that it's fully
43:56managed so you pay for
44:00use and it is elastic basically growing
44:03and shrinking completely handsfree this
44:06can get expensive but it's very
44:09convenient because you don't have to
44:10worry about a lot of the stuff we're
44:12talking about here so there are a lot of
44:13options out there where you basically
44:15pay for usage and it's fully managed
44:18which could actually be beneficial if
44:20you're accidentally overr provisioning
44:22your servers you might be wasting money
44:25so having either elastic features with
44:27that main server or just going
44:29completely serverless could actually
44:31save you some money so just definitely
44:33something you should look into and at
44:34least be aware that serverless databases
44:37are a thing and can be pretty handy
44:39they'll do all of the clustering and
44:42database management for you behind the
44:44scenes at this point you have a pretty
44:46good idea of the general structure for
44:48software architecture and now going into
44:51the upcoming videos you'll be much more
44:53equipped to fill in knowledge and learn
44:55all of these things at a deeper level I
44:57look forward to seeing you in the next
44:58video if you've enjoyed the content
45:00please be sure to subscribe and check
45:01out my resource links down below if you
45:04want some additional help and useful
45:06resources thank you I'll see you in the
45:08next one

About this transcript

This page contains the full transcript of Essential System Design Concepts You Should Know - System Design Tutorial by Caleb Curry, generated from the public captions YouTube serves with the video. The transcript has 7,752 words across 1,126 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.