{"id":22166060,"url":"https://github.com/alextanhongpin/system-design-learn","last_synced_at":"2026-01-04T23:43:16.508Z","repository":{"id":79115276,"uuid":"255114797","full_name":"alextanhongpin/system-design-learn","owner":"alextanhongpin","description":"Learning system design basics","archived":false,"fork":false,"pushed_at":"2020-05-08T14:11:44.000Z","size":8,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-01-29T21:51:39.026Z","etag":null,"topics":["estimate","system-design"],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/alextanhongpin.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-04-12T15:39:54.000Z","updated_at":"2020-12-27T17:29:09.000Z","dependencies_parsed_at":null,"dependency_job_id":"91c1487c-fffc-4492-9948-c34478ba617b","html_url":"https://github.com/alextanhongpin/system-design-learn","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alextanhongpin%2Fsystem-design-learn","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alextanhongpin%2Fsystem-design-learn/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alextanhongpin%2Fsystem-design-learn/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alextanhongpin%2Fsystem-design-learn/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/alextanhongpin","download_url":"https://codeload.github.com/alextanhongpin/system-design-learn/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245304868,"owners_count":20593626,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["estimate","system-design"],"created_at":"2024-12-02T05:17:56.356Z","updated_at":"2026-01-04T23:43:16.447Z","avatar_url":"https://github.com/alextanhongpin.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# system-design-learn\nLearning system design basics\n\n\n# Seven steps for system design interviews\n\n\n- **Step 1: Requirements clarification:** Always ask a question to find the exact scope of the problem you are solving\n- **Step 2: System interface definition:** Define what APIs are expected from the system. This will also ensure you haven't gotten any requirement wrong.\n- **Step 3: Back-of-the-envelope estimation:** Also called the Fermi problem, it's good to always have a good estimate on the scale of thes system you are going to design\n- **Step 4: Define data model:** This helps you decide on how data are partitioned.\n- **Step 5: High-level design:** Block diagrams to represent core components of the system.\n- **Step 6: Detailed component design:** Dig deeper into 2-3 components \n- **Step 7: Bottlenecks:** Try to discuss as many bottlenecks as possible - and find ways to mitigate them. Note that sometimes it is impossible to mitigate them, so you need to understand what is the tradeoff of the approach you choose.\n\n\n## Gathering Requirements\n\nAccording to wiki, the process of defining, maintaining and documenting requirements is called [requirements engineering](https://en.wikipedia.org/wiki/Requirements_engineering). To simplify things, we focus on gathering _functional_ and _[non-functional](https://en.wikipedia.org/wiki/Non-functional_requirement)_ requirements. We use the shortform **FR** for functional requirements and **NFR** for non-functional requirements:\n\nHere's the difference:\n- FR define _what a system is supposed to do_, NFR _how a system is supposed to be_.\n- FR \"system shall do \u003crequirement\u003e\", NFR \"system shall be \u003crequirement\u003e\"\n\n## Capacity Estimations and Constraints\n\n- Traffic estimates. Is the system read or write heavy? e.g. 20/1 read to write ratio. To hit slightly more than 1 million requests per day, we only need 12 requests per second (1,000,000 / 60 / 60 / 24). \n- Storage estimates. 1 mil requests, each of size 1kb will require 1MB storage.\n- Bandwidth estimates. 1 mil requests per second, each of size 100kb will result in 1MB/s.\n- Memory estimates, usually for cache. \n\n\n## System Components\n\n### Load balancer vs reverse proxy\n\nA **reverse proxy** accepts a request from a client, forwards it to a server that can fulfil it, and returns the server's response to the client.\n\nA **load balancer** distributes incoming client requests among a group of servers, in each case returning the response from the selected servers to the appropriate client.\n\nNginx is able to serve as both load balancer and reverse proxy.\n\nReference: https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/\n\n### Load balancing algorithm\n\n- round robin\n- weighted round robin - same as round robin, but some servers gets a larger share of the overall traffic\n- source ip hash - connections are distributed to backend servers based on the source ip address. If a webnode fails and is taken out of service the distribution changes. As long as all servers are running a given client ip address will always go to the same web server.\n- url hash. Much like source IP hash, except hashing is done on the URL of the request. Useful when load balancing in front of proxy caches, as requests for a given object will always go to just one backend cache. This avoids cache duplication, having the same object stored in several / all caches, and increases effective capacity of the backend caches.\n- least connections, weighted least connections. The load balancer monitors the number of open connections for each server, and sends to the least busy server.\n- least traffic, weighted least traffic. The load balancer monitors the bitrate from each server, and sends to the server that has the least outgoing traffic.\n- leat latency. Perlbal makes a quick HTTP OPTIONS request to backend servers, and sends the request to the first server to answer.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falextanhongpin%2Fsystem-design-learn","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falextanhongpin%2Fsystem-design-learn","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falextanhongpin%2Fsystem-design-learn/lists"}