I ACED my Technical Interviews knowing these System Design Basics

0:00 design a social media platform that can handle millions of user requests where do you even start from here today we'll walk through core fundamentals that you need to get started we can start with a simple web server and one database to store your user data however this will not scale as your user base grows so distributed system are the go-to solution these are network of independent computers working as one coherent system when we talk about distributed system we need to understand the key characteristics scalability this is the system ability to handle growing demands there are two ways to scale horizontal scaling by adding more servers and vertical scaling by upgrading existing Hardwares reliability a reliable system continues to function correctly even when components fail

0:45 availability is the percentage of time a system remains operational this is often expressed in nines for example 99.9% availability means the system is down for no more than 8.76 hours per year while 99.99% with would only be down for 52.6 minutes per year efficiency measured by two main factors latency which is the delay in getting the first response and throughput which is the number of operations handled in a given time these characteristics often involve trade-offs your goal is to balance these factors based on the given requirements although ideal distributed system face inherent limitations the cap theorum states that a distributed system can only guarantee two out of the three properties consistency all notes display identically data guaranteeing that reads

1:31 always reflect the most recent rate availability every request receives a respond without guaranteeing that the data is the most recent partition tolerant the system continues to function despite Network failures between note this trade-off is crucial in designing distributed system influencing how systems handle data updates and respon to failures now our architecture uses multiple web servers which is amazing because we can handle more load by adding more servers but what happens if one server ends up receiving more requests than others to manage distributed system load efficiently we need a load balancer which distributes incoming requests across multiple servers to ensure that no single servers becomes overwhelmed if one server goes down the load balancer will only redirect traffic to healthy servers a load balancer can be placed at

2:18 various levels between the users and web servers between web servers and application servers and between the application servers and databases there are several algorithms load balancers used to distribute traffic such as lease connection method sends request to server with the fewest active connections round robin cycle through a list of servers sequentially IP hash uses the client's IP address to determine which server receives the request which one to use really depends on the specific needs it's also worth noting that load balancer itself could become a single point of failure to prevent this we can add another load balancer for standby if the primary one fails the second one takes over immediately things are going great so far but we start to notice that these servers often request the same data to

3:04 our database that's where caching comes into play caching takes advantage of the principle that recently requested data is likely to be requested again retrieving data from cash is typically way faster than from the original database aside from application cache there is also content delivery Network or CDN which is ideal for serving static media cdns cach content closer to the user to reduce latency however caching does come with its own set of challenges which is maintaining data consistency and making sure that the data is in sync with the source of Truth we don't want to serve the data from cash if it's not up to date this leads us to cash and validation strategies write through data is written to both cash and storage at the same time uring consistency but increasing right latency right around

3:50 data bypasses the cash and goes directly to the storage preventing cash flooding but potentially increasing read latency for new data right back data is written to cash first and later to storage offering low latency but risking data loss in case of system failures when a cach reaches capacity we need eviction policy to make room for new data some common ones are least recently used removes the least recently accessed data first in first out removes the oldest item first and least frequently used removes the least often accessed items as our platform grows we need to think about storage strategy should we stick with a traditional SQL database or go with no SQL SQL stores data and tables with

4:35 predefined schemas each row contains all the information about a piece of record if you want to add a new column the changes would need to be applied to all the records in the table popular SQL database include MySQL Oracle and postgress nosql on the other hand is a non-relational databases that have a more flexible data structure they come in four main types key value stores like redis document databases like m DB wide column like Cassandra graph databases like neo4j when comparing SQL versus no SQL we often look at the structure SQL has a rigid schema while no SQL has a more flexible schema querying SQL databases use standard structured query language while no SQL databases queries are more focused on collection of

5:21 documents in terms of scalability SQL typically scales vertically although can be done horizontally through sharting while no SQL scales hor onally reliability SQL is AIT compliant while no SQL often sacrifices this for performance and scalability AIT refers to a set of principle where automac City ensures that transaction is fully completed or not at all consistency guarantees that a transaction takes a database from one valid state to another enforcing all defined rules isolation keeps transactions separate so their operations don't interfere with each other durability ensures that once a transaction is committed it remains permanent even in case of failure so which one to use we want to use SQL when we need access compliance than financial applications and when our data structure

6:08 doesn't change often no SQL would be a good option if we're dealing with large volumes of unstructured data or if we're in need of Rapid development that requires a lot of flexibility after choosing our database we notice that queries are really slow and we need to fix this ASAP we notice that data that we're querying doesn't have an index so we're constantly having to search through the entire user table every single time indexes work by creating a separate data structure that points to the location of the actual data speeding up search operations the most common types of indexes are primary key the unique identifier for each record in the table secondary index the additional index on a non-p primary key columns for faster search query such as searching for users's first name Composite Index which created on multiple columns useful

6:54 for queries involving those columns together such as first name and last name not an end but worth mentioning foreign key which is a constraint that enforces a relationship between columns and different tables while index is dramatically improve read performance they can also slow down right operations this is because every time you insert update or delete data the index must also be updated that's why it's very important that we are decisive and intentional when creating indexes because we designed such an amazing platform so many users decide to sign up for this app and that we're now facing challenges with the sheer volume of data our database is literally going to explode so you try to beef up your database by adding more Hardware but the growth continues and it's just not enough when our database can no longer

7:40 scale vertically we can look into Data partitioning which is a technique for breaking large databases into smaller more manageable Parts this improves performance availability and load balancing as your application scale there are three main partitioning methods horizontal partitioning which divides rows of a table across multiple data bases vertical partitioning separates entire features or columns into two different databases and directory based partitioning uses a lookup service to abstract the partitioning scheme partitioning can be done on various criteria key or hash base applies a hash function to a key attribute to determine which partition the data belongs to a notable approach here is consistent hashing which is a technique that minimizes data redistribution when scaling the number

8:26 of servers at a very high level it works by Distributing data across some number of servers around a hash ring each data is hashed to determine which server it belongs to each server is also only responsible for a portion of the hash range when adding or removing servers only a small fraction of data needs to be remapped this makes it very easy to scale dynamically and reduces the impact of server changes list partitioning assign each partition a list of value storing each data based on which list its key belongs to round robin this distribute data evenly across partition in a circular order composite partitioning combines two or more partitioning methods while partitioning solve scaling issues it also introduces its own challenges like difficulty in

9:12 joining across multiple partitions leading to potentially tricky data rebalancing we've taken our social media platform from a simple single server setup to a robust scalable architecture I couldn't cover everything in this introductory overview to system design and there's just so much more to cover if you're interested let me know if you want to see more of this but I hope that you are able to learn something new today as always thank you so much for watching and see you in the next one