More System design

Author: theEmbeddedGeorge

Interview/Algorithm/Array.md

@@ -16,6 +16,7 @@
 14. Maximum Swap
 15. Meeting Room II
 16. Sort Colors
+17. 3 Sum
 
 ## Implementation
 
@@ -621,4 +622,42 @@ public:
     }
 
 };
+```
+
+### **3 SUM**
+
+***Big O:*** O(n^2), O(1) space
+```
+Tips: 
+
+Sort + two pointers.
+```
+```c++
+class Solution {
+public:
+	vector<vector<int>> threeSum(vector<int>& nums) {
+		vector<vector<int>> ans;
+		sort(nums.begin(), nums.end());
+		int length = nums.size() - 1, left, right;
+		for ( int index = 0; index <= length; ++index )
+		{
+			if ( index > 0 && nums[index - 1] == nums[index] ) continue; 
+			left = index + 1;
+			right = length;
+			while ( left < right )
+			{
+				if ( nums[index] + nums[left] + nums[right] < 0 ) ++left;
+				else if ( nums[index] + nums[left] + nums[right] > 0 ) --right;
+				else
+				{
+					vector<int> anotherAnswer { nums[index], nums[left], nums[right] };
+					ans.push_back(anotherAnswer);
+					++left;
+					while ( left < right && nums[left] == nums[left - 1] ) ++left;
+				}   
+			}    
+		}     
+		return ans;
+	}
+};
 ```

Interview/Algorithm/LeetCode_for_embedded_advanced.md

@@ -81,6 +81,7 @@
 31. Maximum Swap                               v
 32. Meeting Room II                            v
 33. Sort Colors                                v
+34. 3 Sum                                      v
 
 ***Math:***
 1.  Add Binary                                 v

Interview/SystemDesign/CAPTheorem.md

@@ -0,0 +1,19 @@
+## CAP Theorem
+
+```CAP theorem states that it is impossible for a distributed software system to simultaneously provide more than two out of three of the following guarantees (CAP): Consistency, Availability, and Partition tolerance.```
+
+When we design a distributed system, trading off among CAP is almost the first thing we want to consider. CAP theorem says while designing a distributed system we can pick only two of the following three options:
+
+***Consistency:*** All nodes see the same data at the same time. Consistency is achieved by updating several nodes before allowing further reads.
+
+***Availability:*** Every request gets a response on success/failure. Availability is achieved by replicating the data across different servers.
+
+***Partition tolerance:*** The system continues to work despite message loss or partial failure. A system that is partition-tolerant can sustain any amount of network failure that doesn’t result in a failure of the entire network. Data is sufficiently replicated across combinations of nodes and networks to keep the system up through intermittent outages.
+
+![CAP theorem](https://miro.medium.com/max/922/1*tmttEOAU9xacJgw6vrsAuA.jpeg)
+
+We cannot build a general data store that is continually available, sequentially consistent, and tolerant to any partition failures. We can only build a system that has any two of these three properties. Because, to be consistent, all nodes should see the same set of updates in the same order. But if the network loses a partition, updates in one partition might not make it to the other partitions before a client reads from the out-of-date partition after having read from the up-to-date one. The only thing that can be done to cope with this possibility is to stop serving requests from the out-of-date partition, but then the service is no longer 100% available.
+
+## Reference
+
+Grokking the System Design Interview by Educative.io

Interview/SystemDesign/Redundancy&Replication.md

@@ -0,0 +1,17 @@
+## Redundancy and Replication
+
+### **Redundancy**
+Redundancy is the ***duplication of critical components or functions of a system*** with the intention of increasing the reliability of the system, usually in the form of a backup or fail-safe, or to improve actual system performance. For example, if there is only one copy of a file stored on a single server, then losing that server means losing the file. Since losing data is seldom a good thing, we can create duplicate or redundant copies of the file to solve this problem.
+
+```Redundancy plays a key role in removing the single points of failure in the system and provides backups if needed in a crisis. For example, if we have two instances of a service running in production and one fails, the system can failover to the other one.```
+
+
+### **Replication**
+
+Replication means ***sharing information to ensure consistency between redundant resources***, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility.
+
+Replication is widely used in many database management systems (DBMS), usually with a primary-replica relationship between the original and the copies. The primary server gets all the updates, which then ripple through to the replica servers. Each replica outputs a message stating that it has received the update successfully, thus allowing the sending of subsequent updates.
+
+## Reference
+
+Grokking the System Design Interview by Educative.io

Interview/SystemDesign/consistentHashing.md

@@ -0,0 +1,52 @@
+## Consistent Hashing
+
+Distributed Hash Table (DHT) is one of the fundamental components used in distributed scalable systems. Hash Tables need a key, a value, and a hash function where hash function maps the key to a location where the value is stored.
+
+Suppose we are designing a distributed caching system. Given ‘n’ cache servers, an intuitive hash function would be ‘key % n’. It is simple and commonly used. But it has two major drawbacks:
+
+1. It is NOT horizontally scalable. Whenever a new cache host is added to the system, all existing mappings are broken. It will be a pain point in maintenance if the caching system contains lots of data. Practically, it becomes difficult to schedule a downtime to update all caching mappings.
+   
+2. It may NOT be load balanced, especially for non-uniformly distributed data. In practice, it can be easily assumed that the data will not be distributed uniformly. For the caching system, it translates into some caches becoming hot and saturated while the others idle and are almost empty.
+
+In such situations, consistent hashing is a good way to improve the caching system.
+
+### **What is Consistent Hashing?**
+
+Consistent hashing is a very useful strategy for distributed caching systems and DHTs. It allows us to distribute data across a cluster in such a way that **will minimize reorganization when nodes are added or removed. Hence, the caching system will be easier to scale up or scale down**.
+
+```In Consistent Hashing, when the hash table is resized (e.g. a new cache host is added to the system), only ‘k/n’ keys need to be remapped where ‘k’ is the total number of keys and ‘n’ is the total number of servers. Recall that in a caching system using the ‘mod’ as the hash function, all keys need to be remapped.```
+
+In Consistent Hashing, objects are mapped to the same host if possible. When a host is removed from the system, the objects on that host are shared by other hosts; when a new host is added, it takes its share from a few hosts without touching other’s shares.
+
+### **How does it work?**
+
+As a typical hash function, consistent hashing maps a key to an integer. Suppose the output of the hash function is in the range of [0, 256]. Imagine that the integers in the range are placed on a ring such that the values are wrapped around.
+
+Here’s how consistent hashing works:
+
+1. Given a list of cache servers, hash them to integers in the range.
+2. To map a key to a server,
+    1. Hash it to a single integer.
+    2. Move clockwise on the ring until finding the first cache it encounters.
+    3. That cache is the one that contains the key. See animation below as an example: key1 maps to cache A; key2 maps to cache C.
+
+![Consistent Hashing](https://uploads.toptal.io/blog/image/129309/toptal-blog-image-1551794743400-9a6fd84dca83745f8b6ca95a2890cdc2.png)
+
+To add a new server, say D, keys that were originally residing at C will be split. Some of them will be shifted to D, while other keys will not be touched.
+
+To remove a cache or, if a cache fails, say A, all keys that were originally mapped to A will fall into B, and only those keys need to be moved to B; other keys will not be affected.
+
+For load balancing, as we discussed in the beginning, the real data is essentially randomly distributed and thus may not be uniform. It may make the keys on caches unbalanced.
+
+To handle this issue, we add “virtual replicas” for caches. Instead of mapping each cache to a single point on the ring, we map it to multiple points on the ring, i.e. replicas. This way, each cache is associated with multiple portions of the ring.
+
+If the hash function “mixes well,” as the number of replicas increases, the keys will be more balanced.
+
+### **Advance Reading**
+[The Ultimate Guide For consistent Hashing](https://www.toptal.com/big-data/consistent-hashing)
+
+In this article, it first reviews the general concept of hashing and its purpose, followed by a description of distributed hashing and the problems it entails. In turn, that will lead us to our title subject.
+
+## Reference
+
+Grokking the System Design Interview by Educative.io

Interview/SystemDesign/dataPartitioning.md

@@ -1,5 +1,67 @@
 ## Data Partitioning
 
+Data partitioning is a technique to break up a big database (DB) into many smaller parts. It is the process of splitting up a DB/table across multiple machines to improve the manageability, performance, availability, and load balancing of an application. The justification for data partitioning is that, after a certain scale point, it is cheaper and more feasible to scale horizontally by adding more machines than to grow it vertically by adding beefier servers.
+
+### **Partitioning Methods**
+
+There are many different schemes one could use to decide how to break up an application database into multiple smaller DBs. Below are three of the most popular schemes used by various large scale applications.
+
+***a. Horizontal partitioning***
+
+In this scheme, we put different rows into different tables. For example, if we are storing different places in a table, we can decide that locations with ZIP codes less than 10000 are stored in one table and places with ZIP codes greater than 10000 are stored in a separate table. This is also called a range based partitioning as we are storing different ranges of data in separate tables. Horizontal partitioning is also called as Data Sharding.
+
+The key problem with this approach is that if the value whose range is used for partitioning isn’t chosen carefully, then the partitioning scheme will lead to unbalanced servers. In the previous example, splitting location based on their zip codes assumes that places will be evenly distributed across the different zip codes. This assumption is not valid as there will be a lot of places in a thickly populated area like Manhattan as compared to its suburb cities.
+
+***b. Vertical Partitioning***
+
+In this scheme, we divide our data to store tables related to a specific feature in their own server. For example, if we are building Instagram like application - where we need to store data related to users, photos they upload, and people they follow - we can decide to place user profile information on one DB server, friend lists on another, and photos on a third server.
+
+Vertical partitioning is straightforward to implement and has a low impact on the application. The main problem with this approach is that if our application experiences additional growth, then it may be necessary to further partition a feature specific DB across various servers (e.g. it would not be possible for a single server to handle all the metadata queries for 10 billion photos by 140 million users).
+
+***c. Directory Based Partitioning***
+
+A loosely coupled approach to work around issues mentioned in the above schemes is to create a lookup service which knows your current partitioning scheme and abstracts it away from the DB access code. So, to find out where a particular data entity resides, we query the directory server that holds the mapping between each tuple key to its DB server. This loosely coupled approach means we can perform tasks like adding servers to the DB pool or changing our partitioning scheme without having an impact on the application.
+
+### **Partitioning Criteria**
+
+***a. Key or Hash-based partitioning:*** 
+
+Under this scheme, we apply a hash function to some key attributes of the entity we are storing; that yields the partition number. For example, if we have 100 DB servers and our ID is a numeric value that gets incremented by one each time a new record is inserted. In this example, the hash function could be ‘ID % 100’, which will give us the server number where we can store/read that record. This approach should ensure a uniform allocation of data among servers. The fundamental problem with this approach is that it effectively fixes the total number of DB servers, since adding new servers means changing the hash function which would require redistribution of data and downtime for the service. A workaround for this problem is to use Consistent Hashing.
+
+***b. List partitioning:***
+
+In this scheme, each partition is assigned a list of values, so whenever we want to insert a new record, we will see which partition contains our key and then store it there. For example, we can decide all users living in Iceland, Norway, Sweden, Finland, or Denmark will be stored in a partition for the Nordic countries.
+
+***c. Round-robin partitioning:***
+
+This is a very simple strategy that ensures uniform data distribution. With ‘n’ partitions, the ‘i’ tuple is assigned to partition (i mod n).
+
+***d. Composite partitioning:***
+
+Under this scheme, we combine any of the above partitioning schemes to devise a new scheme. For example, first applying a list partitioning scheme and then a hash based partitioning. Consistent hashing could be considered a composite of hash and list partitioning where the hash reduces the key space to a size that can be listed.
+
+### **Common Problems of Data Partitioning**
+
+On a partitioned database, there are certain extra constraints on the different operations that can be performed. Most of these constraints are due to the fact that operations across multiple tables or multiple rows in the same table will no longer run on the same server. Below are some of the constraints and additional complexities introduced by partitioning:
+
+***a. Joins and Denormalization:***
+
+Performing joins on a database which is running on one server is straightforward, but once a database is partitioned and spread across multiple machines it is often not feasible to perform joins that span database partitions. Such joins will not be performance efficient since data has to be compiled from multiple servers. A common workaround for this problem is to denormalize the database so that queries that previously required joins can be performed from a single table. Of course, the service now has to deal with all the perils of denormalization such as data inconsistency.
+
+***b. Referential integrity:***
+
+As we saw that performing a cross-partition query on a partitioned database is not feasible, similarly, trying to enforce data integrity constraints such as foreign keys in a partitioned database can be extremely difficult.
+
+Most of RDBMS do not support foreign keys constraints across databases on different database servers. Which means that applications that require referential integrity on partitioned databases often have to enforce it in application code. Often in such cases, applications have to run regular SQL jobs to clean up dangling references.
+
+***c. Rebalancing:***
+
+There could be many reasons we have to change our partitioning scheme:
+
+The data distribution is not uniform, e.g., there are a lot of places for a particular ZIP code that cannot fit into one database partition.
+There is a lot of load on a partition, e.g., there are too many requests being handled by the DB partition dedicated to user photos.
+
+In such cases, either we have to create more DB partitions or have to rebalance existing partitions, which means the partitioning scheme changed and all existing data moved to new locations. Doing this without incurring downtime is extremely difficult. Using a scheme like directory based partitioning does make rebalancing a more palatable experience at the cost of increasing the complexity of the system and creating a new single point of failure (i.e. the lookup service/database).
 
 ## Reference
 

Interview/SystemDesign/indexes.md

@@ -0,0 +1,27 @@
+## Indexes
+
+Indexes are well known when it comes to databases. Sooner or later there comes a time when database performance is no longer satisfactory. One of the very first things you should turn to when that happens is database indexing.
+
+The goal of creating an index on a particular table in a database is to make it faster to search through the table and find the row or rows that we want. Indexes can be created using one or more columns of a database table, providing the basis for both rapid random lookups and efficient access of ordered records.
+
+```Indexes is like the table of contents that provides fast retrival of contents from a large database.``` 
+
+### **Example: A Library Catalog**
+
+A library catalog is a register that contains the list of books found in a library. The catalog is organized like a database table generally with four columns: book title, writer, subject, and date of publication. There are usually two such catalogs: one sorted by the book title and one sorted by the writer name. That way, you can either think of a writer you want to read and then look through their books or look up a specific book title you know you want to read in case you don’t know the writer’s name. These catalogs are like indexes for the database of books. They provide a sorted list of data that is easily searchable by relevant information.
+
+Simply saying, an index is a data structure that can be perceived as a table of contents that points us to the location where actual data lives. So when we create an index on a column of a table, we store that column and a pointer to the whole row in the index.
+
+Just like a traditional relational data store, we can also apply this concept to larger datasets. The trick with indexes is that we must carefully consider how users will access the data. In the case of data sets that are many terabytes in size, but have very small payloads (e.g., 1 KB), indexes are a necessity for optimizing data access. Finding a small payload in such a large dataset can be a real challenge, since we can’t possibly iterate over that much data in any reasonable time. Furthermore, it is very likely that such a large data set is spread over several physical devices—this means we need some way to find the correct physical location of the desired data. Indexes are the best way to do this.
+
+### **How do Indexes decrease write performance?**
+
+An index can ***dramatically speed up data retrieval but may itself be large due to the additional keys, which slow down data insertion & update***.
+
+When adding rows or making updates to existing rows for a table with an active index, we not only have to write the data but also have to update the index. This will decrease the write performance. This performance degradation applies to all insert, update, and delete operations for the table. For this reason, adding unnecessary indexes on tables should be avoided and indexes that are no longer used should be removed. To reiterate, adding indexes is about improving the performance of search queries. 
+
+```If the goal of the database is to provide a data store that is often written to and rarely read from, in that case, decreasing the performance of the more common operation, which is writing, is probably not worth the increase in performance we get from reading.```
+
+## Reference
+
+Grokking the System Design Interview by Educative.io