I ACED my Technical Interviews knowing these System Design Basics

[00:00] Design a social media platform that can handle millions of user quality. Where can 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 for your user data.

[00:13] However, this will not scale as your user base grows. So distributed systems are the go-to solutions. These are network of independent computers working as one coherent system. When we talk about distributed systems, we need to understand the key characteristics.

[00:28] Scalability, this is the system's ability to handle growing demands. There are two ways to scale, horizontal scaling by adding more service and vertical scaling by upgrading existing hardware.

[00:40] Reliability, a reliable system continues to function correctly even when components fail. Availability is the percentage of time a system remains operational. This is often expressed in lines.

[00:52] For example, 99.9% availability means the system is down for no more than 8.76 hours per year, while 99.99% 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,

[01:09] 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 systems face inherent limitations,

[01:22] the CAAT theorem states that a distributed system can only guarantee two out of the three properties. Consistency, all nodes display identical data, guaranteeing that rates always reflect the most recent write.

[01:34] Availability, every request receives a response without guaranteeing that the data is the most recent. Partition tolerance, the system continues to function despite network failures between nodes. This trade-off is crucial in designing distributed systems, influencing how systems handle data updates in response to failures.

[01:51] 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 systems load efficiently, we need a load balancer which distributes incoming requests across multiple servers to ensure that no single server becomes overwhelmed.

[02:11] If one server goes down, the load balancer will only redirect traffic to healthy servers. A load balancer can be placed at 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 use to distribute traffic such as leaf connection method

[02:32] Since requests a 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.

[02:46] 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.

[02:58] Things are going great so far, but we start to notice that these servers often request the same data to our database. That's where caching comes into play. Caching takes advantage of the principle that recently requested data is likely to be requested

[03:12] again. data from cache is typically way faster than from the original database. Aside from application cache, there is also Content Delivery Network , which is ideal for serving static media. CBNs caches content closer to the user to reduce latency. However, caching does come

[03:29] with its own sets 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 cache if it's not up to date. This leads us to cache and validation strategies. Write

[03:42] Data is written to both cache and storage at the same time, ensuring consistency but increasing write latency. Write around, data bypasses the cache and goes directly to the storage, preventing cache flooding but potentially increasing relatency for new data.

[03:57] Write back, data is written to cache first and later to storage, offering low latency but risking data loss in case of system failures. When a cache reaches capacity, we need a vision policy to make room for new data.

[04:11] Some common ones are Least Recently Used, remove the least recently accessed data. First In-First Art, remove the oldest item first. And Least Frequently Used, remove the least often accessed items.

[04:26] As our platform grows, we need to think about storage strategy. Should we stick with a traditional SQL database or go with NoSQL? SQL stores data in tables with predefined schemas. Each row paints all the information about a piece of records. If you want to add a new column, the changes will need to be applied to all the records in the table.

[04:45] Popular SQL databases include MySQL Oracle and Postgres NoSQL on the other hand is a non databases that have a more flexible data structure They come in four main types key value stores

[04:57] like Redis, document databases like MongoDB, wide column like Cassandra, graph databases like Neo4j. When comparing SQL versus NoSQL, we often look at the structure. SQL has a rigid schema while NoSQL

[05:11] has a more flexible schema. Querying SQL databases use standard structure query language, while NoSQL databases queries are more focused on collection of documents. In terms of scalability, SQL typically scales vertically,

[05:26] also can be done horizontally through sharding, while NoSQL scales horizontally. Reliability SQL is access-compliant, while NoSQL often sacrifices this for performance and scalability.

[05:38] ACID refers to a set of principles where atomicity ensures that a 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.

[05:51] Isolation keeps transactions separate so that operations don't interfere with each other. Verability ensures that once a transaction is committed, it remains permanent even in case of failure. So which one to use?

[06:03] We want to use SQL when we need access compliance, think financial applications, and when our data structure doesn't change often. NoSQL 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.

[06:18] 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 switch through the entire user's table every single time.

[06:31] 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.

[06:44] Secondary index, the additional index on a non-primary key column for faster search rate, such as searching for users' first name. Composite index, created on multiple columns, useful for queries involving both columns together, such as first name and last name.

[06:59] Not an index, but worth mentioning foreign key, which is a constraint that enforces a relationship between columns and different tables. While indexes dramatically improve read performance they can also slow down write operations This is because every time you insert update or delete data the index must also be updated That why it very important that we are decisive and intentional when creating indexes

[07:21] Because we designed such an amazing platform, so many users decided to stand 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.

[07:35] But the growth continues and it's just not enough. When our database can no longer scale vertically, we can look into data partitioning, which is a technique for breaking large databases into smaller, more manageable parts.

[07:48] This improves performance, availability, and load balancing of your application scale. There are three main partitioning methods. Horizontal partitioning, which divides rows of a table across multiple databases.

[08:00] Vertical partitioning separates entire features or columns into different databases. and directory-based partitioning uses a lookup service to abstract a partitioning scheme. Partitioning can be done on various criteria, key or hash-based.

[08:14] 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 of servers.

[08:27] At a very high level, it works by distributing data across a number of servers around a hash thing. Each data is hashed to determine which server it belongs to. Each server is also only responsible for a portion of the hash range.

[08:41] When adding or removing servers, only a small fraction of data needs to be remapsed. This makes it very easy to scale dynamically and reduces the impact of server changes. List Partitioning Assign each partition a list of values, storing each data based on which list it's key belongs to.

[08:58] Round Robin Distribute data evenly across partition in a circular order. Composite partitioning combines two or more partitioning methods. While partitioning solves scaling issues, it also introduces its own challenges like difficulty in joining across multiple partitions, leading to potentially tricky data rebalancing.

[09:18] 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.

[09:31] If you're interested, let me know if you want to see more of this, but I hope that you were able to learn something new today. As always, thank you so much for watching, and see you in the next one.