20 System Design Concepts Explained in 10 Minutes

do you want to level up from Junior Dev so that you can build scalable apps or maybe get a 100K pay Bump by passing your system design interview round well you're gonna need a box of neat codes 20 essential system Design Concepts which include networking API patterns databases and more all of which are covered more extensively on neetcode.io to start let's say you have a single server which is accepting and fulfilling requests for your application but now we're getting more users so we need to scale it the easiest thing to do would be to add

more resources like Ram or maybe upgrade your CPU this is known as vertical scaling it's pretty easy but it's very limited a better approach would be to add replicas so that each server can handle a subset of requests this is known as horizontal scaling it's more powerful because we can almost scale infinitely and we don't even need good machines it also adds redundancy and fault tolerance because if one of our servers goes down all of the other servers can continue to fulfill requests this eliminates our previous single point of failure but the downside is that

this approach is much more complicated first of all how do we ensure that one server won't get overloaded while the others sit idle well for that we'll need a load balancer which is just a server known as a reverse proxy it directs incoming requests to the appropriate server so we can use an algorithm like round robin which will balance traffic by cycling through our pool of servers or we could go with another approach like hashing the incoming request ID in our case the goal is to even the amount of traffic each server is getting but

if our servers are located all around the world we could even use a load balancer to route a request to the nearest location which brings us to content delivery networks if you're just serving static files like images videos and sometimes even HTML CSS and JavaScript files you can just use a CDN it's a network of servers located all around the world cdns don't really run any application logic they work by taking files hosted on your server aka the origin server and copying them onto the CDN servers this can be done either on a push or

pull basis but cdns are just one technique for caching which is all about creating copies of data so that it can be refetched faster in the future making Network requests can be expensive so our browsers will sometimes cache data onto our disk but reading disk can be expensive so our computers will copy it into memory but reading memory can be expensive so our operating systems will copy a subset of it into our L1 L2 or L3 CPU cache but how do computers communicate with each other well well every computer is assigned an IP address which

uniquely identifies a device on a network and to round it all out we have the poorly named TCP slash IP or the Internet Protocol Suite since it actually includes UDP as well what but focusing on TCP for a second there has to be some set of rules AKA protocols that decide how we send data over the Internet just like how in real life we have a system that decides how we send mail to each other usually when we send data like files they're broken down into individual packets and they're sent over the internet and when

they arrive at the destination the packets are numbered so that they can be reassembled in the same order if some packets are missing TCP ensures that they'll be resent this is what makes it a reliable protocol and why many other protocols like HTTP and websockets are built on top of TCP but when you type neetcode.io into your search bar how does your computer know which IP address it belongs to well for that we have the domain name system which is a largely decentralized service that works to translate a domain to its IP address when you

buy a domain from a DNS registrar you can create a dnsa record which stands for address and then you can enter the IP address of your server so then when you search and your computer makes a DNS query to get the IP address it'll use the a record mapping to get the address and then your operating system will cache it so that it doesn't need to make a DNS query every single time but wait a minute why do we usually use HTTP to view websites well TCP is too low level we don't want to have

to worry about individual data packets so we have an application Level protocol like HTTP which is what developers like like you and I actually use on a day-to-day basis it follows the client server model where a client will initiate a request which includes two parts one the request header think of that as the shipping label you put on a package it tells you where the package is going who it's from and maybe some other metadata about the package itself the second part is the request body which is basically the package contents to test it out

just open your Dev tools Network Tab and click subscribe go on always taking a closer look at the request we can see that the response also includes a header as well as a body but even with HTTP there are multiple API patterns we could follow the most popular one being rest which is a standardization around HTTP apis making them stateless and following consistent guidelines like a successful request should include a 200 code in its response header whereas a bad request from the client would return a 400 code and an issue with the server would result

in a 500 level code graphql is another API pattern introduced by Facebook in 2015. the idea is that instead of making another request for every single resource on your server like you would do with rest with graphql you can just make a single request AKA a query and you can choose exactly which resources you want to fetch this means you can fetch multiple resources with a single request and you also don't end up over fetching any data that's not actually needed another API pattern is grpc though it's really considered a framework released by Google in

2016 it was also meant to be an improvement over rest apis it's an RPC framework mainly used for server-to-server communication but there's also grpc web which allows using grpc from a browser which has also been growing quickly over the last few years the performance boost comes from protocol buffers comparing them to Json which is what rest apis use protocol buffers are an improvement in that data is serialized into a binary format which is usually more storage efficient and of course sending less data over a network will usually be faster the downside is that Json is

a lot more human readable since it's just plain text another app layer protocol is websockets to understand the main problem that it solves let's take chat apps for example usually when someone sends you a message you receive it immediately if we were to implement this with HTTP we would have to use polling where we would periodically make a request to check if there was a new message available for us but unlike HTTP 1 websockets support bi-directional communication so when you get a new message it's immediately pushed to your device and whenever you send a message

it's immediately pushed to the receiver's device and for actually storing data we have SQL or relational database Management Systems like MySQL and postgres but why should we use a database when we can just store everything in text files stored on disk well with databases we can more efficiently store data using data structures like B trees and we have fast retrieval of data using SQL queries since data is organized into rows and tables relational database Management systems are usually acid compliant which means that they offer durability because data is stored on disk so even if a

machine restarts the data will still be there isolation means that different concurrent transactions won't interfere with each other atomicity means that every transaction is All or Nothing lastly we have consistency which means that foreign key and other constraints will always be enforced this one is really important because it led to the creation of nosql or non-relational databases consistency makes databases harder to scale so no SQL databases drop this constraint and the whole idea of relations all together there are many types of nosql databases but popular ones include key value stores document stores and graph databases

but going back to consistency for a second if we don't have to enforce any foreign key constraints that means we can break up our database and scale it horizontally with different machines this technique is called sharding but how do we decide which portion of the data to put on which machine well for that we usually have a Shard key so given a table of people our Shard key could be the ID of the person but sharding can get complicated a simpler approach is replication if we want to scale our database reads we can make read-only

copies of our database this is called leader follower replication wherever every right will get sent to the leader who sends those to the followers but every read could go to a leader or a follower there's also leader leader replication where every replica can be used to read or write but this can result in inconsistent data so it would be best to use it where you can have a replica for every region in the world for example it can be complex to keep replicas in sync so the cap theorem was created to weigh trade-offs with replicated

design it states that given a network partition in a database as database designers we can only choose to favor either data consistency or data availability what makes it confusing is that consistency here means something different than with acid it's a somewhat controversial theorem which is why the more complete pack else theorem was created lastly we have message cues they're kind of like databases because they have durable storage and they can be replicated for redundancy see or sharded for scalability but they have many use cases if our system was receiving more data than it can process

it would be good to introduce a message queue so that our data can be persisted before we're able to process it in doing so we also get the added benefit that different parts of our app can become decoupled and if you've learned anything by now it's that software engineering is all about finding new and complicated ways to store and move data around if you want to learn more you can check out my system design for beginners course on neetcode.io as well as my system design interview course thank you for supporting my work and I'll see

you soon