{"id":15622036,"url":"https://github.com/bregman-arie/system-design-notebook","last_synced_at":"2025-03-29T16:11:07.789Z","repository":{"id":43602820,"uuid":"287950119","full_name":"bregman-arie/system-design-notebook","owner":"bregman-arie","description":"Learn System Design step by step","archived":false,"fork":false,"pushed_at":"2023-08-06T18:56:04.000Z","size":2143,"stargazers_count":1041,"open_issues_count":3,"forks_count":240,"subscribers_count":19,"default_branch":"master","last_synced_at":"2025-02-04T16:49:57.088Z","etag":null,"topics":["architecture","cache","dns","exercises","load-balancer","scalability","throughput"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bregman-arie.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2020-08-16T13:35:18.000Z","updated_at":"2025-02-04T14:20:03.000Z","dependencies_parsed_at":"2024-01-13T17:55:07.655Z","dependency_job_id":"71691c20-7d90-4791-aa20-10f3d3698c7a","html_url":"https://github.com/bregman-arie/system-design-notebook","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/bregman-arie%2Fsystem-design-notebook","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bregman-arie%2Fsystem-design-notebook/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bregman-arie%2Fsystem-design-notebook/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bregman-arie%2Fsystem-design-notebook/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bregman-arie","download_url":"https://codeload.github.com/bregman-arie/system-design-notebook/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246207506,"owners_count":20740723,"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":["architecture","cache","dns","exercises","load-balancer","scalability","throughput"],"created_at":"2024-10-03T09:52:37.301Z","updated_at":"2025-03-29T16:11:07.766Z","avatar_url":"https://github.com/bregman-arie.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/system_design_notebook.png\"/\u003e\n\u003c/p\u003e\n\n\u003e An open source project to help you learn about system design step by step\n\n**NOTE:** The work on this repo is still in progress. Some information might be lacking or missing at this point.\n\n* [Topics](#topics)\n* [Topics Explained](#topics-explained)\n* [Exercises](#exercises)\n  * [General](#general)\n  * [AWS Cloud](#aws-cloud)\n  * [Misc](#misc-exercises)\n* [Questions](#Questions)\n* [Resources](#Resources)\n* [System Design](#system-designs)\n  * [Cloud](#system-design-cloud)\n  * [Development](#system-design-development)\n  * [Generic Systems](#system-design-generic-systems)\n  * [Real-World Systems](#system-design-real-world-systems)\n* [System Design Process](#system-design-process)\n* [Interview Tips](#system-design-interview-tips)\n* [Q\u0026A](common-qa.md)\n* [Credits](credits.md)\n\n## System Design\n\n### Requirements\n\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"requirements/README.md\"\u003e\u003cimg src=\"images/requirements/requirements.png\" width=\"160px;\" alt=\"Requirements\" /\u003e\u003cbr /\u003e\u003cb\u003eRequirements\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"requirements/README.md#functional-requirements\"\u003e\u003cimg src=\"images/requirements/functional_requirements.png\" height=\"120px;\" alt=\"Functional Requirements\" /\u003e\u003cbr /\u003e\u003cb\u003eFunctional Requirements\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"requirements/README.md#non-functional-requirements\"\u003e\u003cimg src=\"images/requirements/non_functional_requirements.png\" height=\"120px;\" alt=\"Requirements\" /\u003e\u003cbr /\u003e\u003cb\u003eNon-Functional Requirements\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Compnents/Services\n\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"basic_architecture/README.md\"\u003e\u003cimg src=\"images/basic_architecture/server.png\" width=\"120px;\" height=\"40px;\" alt=\"Server\" /\u003e\u003cbr /\u003e\u003cb\u003eServer\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"basic_architecture/README.md\"\u003e\u003cimg src=\"images/basic_architecture/client.png\" width=\"100px;\" height=\"100px;\" alt=\"Client\" /\u003e\u003cbr /\u003e\u003cb\u003eClient\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n      \u003ctd align=\"center\"\u003e\u003ca href=\"services/load_balancer/README.md\"\u003e\u003cimg src=\"images/services/load_balancer.png\" width=\"75px;\" height=\"75px;\" alt=\"Load Balancer\" /\u003e\u003cbr /\u003e\u003cb\u003eLoad Balancer\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"services/api_gateway/README.md\"\u003e\u003cimg src=\"images/services/api_gateway.png\" width=\"75px;\" height=\"75px;\" alt=\"API Gateway\" /\u003e\u003cbr /\u003e\u003cb\u003eAPI Gateway\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"services/dns/README.md\"\u003e\u003cimg src=\"images/dns/dns.png\" width=\"75px;\" height=\"75px;\" alt=\"DNS\" /\u003e\u003cbr /\u003e\u003cb\u003eDNS\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Scalability\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"scalability/README.md\"\u003e\u003cimg src=\"images/scalability/scalability.png\" width=\"70px;\" height=\"75px;\" alt=\"Scalability\" /\u003e\u003cbr /\u003e\u003cb\u003eScalability\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"scalability/README.md#horizontal-scaling\"\u003e\u003cimg src=\"images/scalability/horizontal_scaling_icon.png\" width=\"300px;\" height=\"75px;\" alt=\"Horizontal Scaling\" /\u003e\u003cbr /\u003e\u003cb\u003eHorizontal Scaling\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"scalability/README.md\"\u003e\u003cimg src=\"images/scalability/vertical_scaling_icon.png\" width=\"300px;\" height=\"60px;\" alt=\"Vertical Scaling\" /\u003e\u003cbr /\u003e\u003cb\u003eVertical Scaling\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"scalability/README.md#scalability_factor\"\u003e\u003cimg src=\"images/scalability/scalability_factor.png\" width=\"100px;\" height=\"80px;\" alt=\"Scalability Factor\" /\u003e\u003cbr /\u003e\u003cb\u003eScalability Factor\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Reliability Engineering\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md\"\u003e\u003cimg src=\"images/reliability_engineering/availability.png\" width=\"75px;\" height=\"75px;\" alt=\"Availability\" /\u003e\u003cbr /\u003e\u003cb\u003eAvailability\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md\"\u003e\u003cimg src=\"images/reliability_engineering/failover.png\" width=\"75px;\" height=\"75px;\" alt=\"Availability\" /\u003e\u003cbr /\u003e\u003cb\u003eFailover\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md#cold-standby\"\u003e\u003cimg src=\"images/reliability_engineering/cold.png\" width=\"75px;\" height=\"75px;\" alt=\"Cold Standby\" /\u003e\u003cbr /\u003e\u003cb\u003eCold Standby\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md#warm-standby\"\u003e\u003cimg src=\"images/reliability_engineering/warm.png\" width=\"85px;\" height=\"75px;\" alt=\"Warm Standby\" /\u003e\u003cbr /\u003e\u003cb\u003eWarm Standby\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n     \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md#hot-standby\"\u003e\u003cimg src=\"images/reliability_engineering/hot.png\" width=\"75px;\" height=\"75px;\" alt=\"Hot Standby\" /\u003e\u003cbr /\u003e\u003cb\u003eHot Standby\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n\n\n### Networking\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"networking/README.md\"\u003e\u003cimg src=\"images/networking/networking.png\" width=\"70px;\" height=\"75px;\" alt=\"Networking\" /\u003e\u003cbr /\u003e\u003cb\u003eNetworking\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Database\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"databases/README.md\"\u003e\u003cimg src=\"images/databases/database.png\" width=\"70px;\" height=\"75px;\" alt=\"Databases\" /\u003e\u003cbr /\u003e\u003cb\u003eDatabases\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"databases/README.md#cap-theorem\"\u003e\u003cimg src=\"images/cap_theorem/cap.png\"  width=\"100px;\" alt=\"CAP\" /\u003e\u003cbr /\u003e\u003cb\u003eCAP Theorem\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Distributed Systems\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"distributed_systems/README.md\"\u003e\u003cimg src=\"images/distributed_systems/distributed_systems.png\" width=\"70px;\" height=\"75px;\" alt=\"Distributed Systems\" /\u003e\u003cbr /\u003e\u003cb\u003eDistrubuted Systems\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"distributed_systems/README.md#clock-diff\"\u003e\u003cimg src=\"images/distributed_systems/clock_drift.png\" width=\"70px;\" height=\"75px;\" alt=\"Clock Drift\" /\u003e\u003cbr /\u003e\u003cb\u003eClock Diff\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"distributed_systems/README.md#cdn\"\u003e\u003cimg src=\"images/distributed_systems/cdn.png\" width=\"90px;\" height=\"75px;\" alt=\"CDN\" /\u003e\u003cbr /\u003e\u003cb\u003eCDN\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n\n### Database\n\u003c!-- ALL-TOPICS-LIST:START --\u003e\n\u003c!-- prettier-ignore-start --\u003e\n\u003c!-- markdownlint-disable --\u003e\n\u003ccenter\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n \n  \u003c/tr\u003e\n\u003c/table\u003e\n\u003c/center\u003e\n\u003c!-- markdownlint-enable --\u003e\n\u003c!-- prettier-ignore-end --\u003e\n\u003c!-- ALL-TOPICS-LIST:END --\u003e\n  \u003ctd align=\"center\"\u003e\u003ca href=\"reliability_engineering/README.md\"\u003e\u003cbr /\u003e\u003cb\u003e\u003c/b\u003e\u003c/a\u003e\u003c/td\u003e\n\n## Exercises\n### General\n#### \"Elementary, my dear Watson\"\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following is an architecture of a server which runs a web server and a database on it. There are a dozen of clients connecting to the server. Answer the following questions\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/general/basic_architecture_db_web.png\"/\u003e\n\u003c/p\u003e\n\n1. Name two issues with this architecture\n   - What term/concept in system design used to describe one of the issues you specified?\n2. Suggest an improvement to the architecture **WITHOUT** adding more components\n   1. If the suggested improvement is \"vertical scaling\", is it a permanent improvement?\n3. Suggest two improvements to the architecture, given that additional components can be added\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n1. Two issues:\n   1. Single point of failure - if the server is down, the users would not be able to connect the application and the server will have to be restored or created from scratch\n   2. If the web process is using all the RAM and/or CPU, then it might affect the DB since it won't have enough resource to handle requests. This is true also the opposite way of DB consuming all resources, not leaving enough for web server processes.\n      - The term used to describe the issue it \"scalability\". The server doesn't scale by demand and eventually users will experience issues\n\n2. Apply [vertical scaling](#vertical-scaling). By adding more resources to the server (i.e. CPU \u0026 RAM) it will allow it to handle more load. This is nota  permanent solution because at some point the load might scale to a point where it's not possible to add more RAM and CPU to the instance nor it's really worthwhile.\n\n3. The two improvements would be:\n   1. Separate DB and web server into two components (instead of both running on the same instance)\n   2. Apply [horizontal scaling](#horizontal-scaling) - add more web server servers (it's also possible to add more DB instances)\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/general/basic_architecture_db_web_solution.png\"/\u003e\n\u003c/p\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n### AWS Cloud\n\n#### What time is it? (stateless application)\n\n\u003cdetails\u003e\n\u003csummary\u003eDesign the most basic architecture for a web application (server based) that tells a single user what time is it (no DB, no scaling, ...) with maximum of two components\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_1.png\"/\u003e\n\u003c/p\u003e\n\nIn this case what you need is two components:\n\n* EC2 instance - this is where our application will run. A basic micro t2 instance is more than enough\n* Elastic IP address - This is the static IP address our user will use every time to reach the application. In case the instance is not operational, we could always move the IP address to one that it is (if we manage more than one instance)\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eYour web app became a huge success and many users start using it. What might be the problem with moving from one user to multiple users and how to deal with it using a single improvement of the architecture?\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nYour instance might not be strong enough to handle requests from multiple users and soon enough you might see RAM and CPU utilized fully. One way to deal with it is, to perform what is called \"Vertical Scaling\" which is the act of adding more resources to your instance. In AWS case, switching to an instance type with more resources like M5 for example.\n\nNote: The problem with vertical scaling (in case you have one node) is downtime (when upgrading the instance type, the instance will be down) so another thing you would want to do is \"Horizontal Scaling\" which is the act of adding more instances/resources.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_2.png\"/\u003e\n\u003c/p\u003e\n\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eYou would like to change the architecture offered in the solution, to not use elastic IP addresses for obvious reasons that it's not really scalable (each EC2 instance has a different IP and users are not able to remember them all). Offer an improvement\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nInstead of using elastic IP addresses we can add a record in the DNS, using the Route 53 service, to have a record from the type A. This way, all users will be able to access the app using an hostname and the IP address will be provided to them by the DNS\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_3.png\"/\u003e\n\u003c/p\u003e\n\nIt's important to note that this solution is not optimal if you plan to scale down and up at some point. Due to the TTL value of a record, a user will keep contacting the same IP address, even if the node is already down.\n\nA more proper and complete architecture would be to use an ELB\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_4.png\"/\u003e\n\u003c/p\u003e\n\nBut even with ELB used and \"Auto scaling group\" for automatically scaling the nodes, this architecture is not optimal. Can you point what is the problem with current architecture? (from two different aspecs)\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eState the issues with current architecture and what would you imrpove\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_4.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nWith current architecture, the application is perhaps able to scale up and down, but when the availability zone is down, your entire application is down. So the first improvement would be to make both ELB and the application itself (the EC2 instances) multi-AZ.\n\nSecondly, if you know you always need an instance (or two) for the application, you might want to have reserved nodes. Reserved nodes means you pay less for instances which means you save on costs.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/what_time_is_it_5.png\"/\u003e\n\u003c/p\u003e\n\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"Video Games Shop\" (stateful application)\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following architecture was proposed for an online video games shop with the requirements of:\n\n  * Support thousands of users at any given point of time\n  * Users can register\n  * Shopping cart items shouldn't be lost when the user browsing the store\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/video_games_shop_1.png\"/\u003e\n\u003c/p\u003e\n\nThe problem is that users report that when they browse for additional video games to buy, they lose their shopping cart. What is the problem with the current architecture and how to deal with it?\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nSuch application is a stateful application, meaning it's important that we'll keep the information about the client from one session to another. It seems that with current architecture, every time the user initiates new session, it's perform against a different instance without saving client information.\n\nThere are a couple of solutions that can be applied in this case:\n  * Load Balancer Sticky Sessions: users will be redirected to the instance they initiated previously session with, in order to to not lose client's data. There is a disadvantage here of losing\n  * User cookies: the client/user stores the relevant data (shopping cart in this case) and in this case it doesn't matter with which EC2 instance the user interacts with, the data on the shopping cart will be sent from the client/user to the relevant instance. The disadvantages: HTTP requests are much heavier because data is attached with each request and it holds some security risks as cookies can be potentially modified\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"Video Games Shop\"\n\n\u003cdetails\u003e\n\u003csummary\u003eFollowing the last exercise, is there another way to deal with user's data (short and long term) except user's cookies and sticky sessions?\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nThere is something called \"server session\" where we need to add a new component to the architecture - ElastiCache or DynamoDB, to store the data on the shopping cart of each user. In order to identify it, we'll use a session ID which will be sent by the client/user every request\n\nFor long term data (user name, address, etc.) we'll use a database (e.g. RDS). There are a couple of variations as to how we can use it. A master instance where we'll write the data and a replication from which we'll read data:\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/video_games_shop_2.png\"/\u003e\n\u003c/p\u003e\n\nA different approach can be to use Cache + DB, where for each session, we'll check if the data is in the cache and if it's not, then we'll access the DB (this is also called \"Write Through\"): \n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/aws_cloud/video_games_shop_3.png\"/\u003e\n\u003c/p\u003e\n\n\u003c/b\u003e\u003c/details\u003e\n\n### Misc\n\nNote: Exercises may repeat themselves in different variations to practice and emphasize different concepts.\n\n#### \"Perfectly balanced, as all things should be\"\n\n\u003cdetails\u003e\n\u003csummary\u003eYou have the following simple architecture of a server handling requests from a client. What are the drawbacks of this design and how to improve it?\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/basic_architecture.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n* Limitations:\n  * Load - at some point it's possible the server will not be able to handle more requests and it will fail or cause delays\n  * Single point of failure - if the server goes down, nothing will be able to handle the requests\n\n* How to improve:\u003cbr\u003e\n  \u003cp align=\"center\"\u003e\n  \u003cimg src=\"images/load_balancer/basic_architecture.png\"/\u003e\n  \u003c/p\u003e\n\n* Further limitations:\n    * Load was handled as well as the server being a single point of failure, but now the load balancer is a single point of failure.\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eIs there a way to improve the above design without adding an actual load balancer instance?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nYes, one could use DNS load balancing.\u003cbr\u003e\nBonus question: which algorithm a DNS load balancer will use?\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat are the drawbacks of round robin algorithm in load balancing?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n  * A simple round robin algorithm knows nothing about the load and the spec of each server it forwards the requests to. It is possible, that multiple heavy workloads requests will get to the same server while other servers will got only lightweight requests which will result in one server doing most of the work, maybe even crashing at some point because it unable to handle all the heavy workloads requests by its own.\n  * Each request from the client creates a whole new session. This might be a problem for certain scenarios where you would like to perform multiple operations where the server has to know about the result of operation so basically, being sort of aware of the history it has with the client. In round robin, first request might hit server X, while second request might hit server Y and ask to continue processing the data that was processed on server X already.\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"For all my actions both public and private\"\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following is an architecture of a load balancer serving and three web servers. Assuming, we would like to have a secured architecture, that makes sense, where would you set a public IP and where would you set a private IP? \n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/public_private_drag_and_drop.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/public_private_drag_and_drop_solution.png\"/\u003e\n\u003c/p\u003e\n\nIt makes sense to hide the web servers behind the load balancers instead of giving users direct access to them, so each one of them will have a private IP assigned to it.\nThe load balancer should have a public IP since, we except anyone who would like to access a certain web page/resource, to go through the load balancer hence, it should be accessible to users.\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat load balancing techniques are there?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n  * Round Robin\n  * Weighted Round Robin\n  * Least Connection\n  * Weighted Least Connection\n  * Resource Based\n  * Fixed Weighting\n  * Weighted Response Time\n  * Source IP Hash\n  * URL Hash\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"Keep calm, all I want is your cash\"\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following is a simple architecture of a client making requests to web server which in turn, retrieves the data from a datastore. What are the drawbacks of this design and how to improve it?\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/cache_basics_1.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n* Limitations:\n  * Time - retrieving the data from the datastore every time a request is made from the client, might take a while\n  * Single point of failure - if the datastore is down (or even slow) it wouldn't be possible to handle the requests\n  * Load - the datastore getting all the requests can result in high load on the datastore which might result in a downtime\n\n* How to improve:\u003cbr\u003e\n  \u003cp align=\"center\"\u003e\n  \u003cimg src=\"images/design/cache_basics_2.png\"/\u003e\n  \u003c/p\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eAre you able to explain what is Cache and in what cases you would use it?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nWhy to use cache?\n\n  * Save time - Accessing a remote datastore, and in general making network calls, takes time\n  * Reduce load - Instead of the datastore handling all the requests, we can take some of its load and reduce by accessing the cache\n  * Avoid repetitive tasks - Instead of querying the data and processing it every time, do it once and store the result in the cache\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eWhy not storing everything in the cache?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nFor multiple reasons:\n\n1. The hardware on which we store the cache is in some cases much more expensive\n2. More data in the cache, the bigger it gets and longer the put/get actions will take\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"In a galaxy far, far away...\"\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following is a system design of a remote database and three applications servers\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/remote_database_1.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n* Limitations:\n  * Latency. Every query made to the remote database will hit latency, even if small.\n  * In case the remote database crashes, the app will stop working\n\n* How to improve:\u003cbr\u003e\n  \u003cp align=\"center\"\u003e\n  \u003cimg src=\"images/design/remote_database_2.png\"/\u003e\n  \u003c/p\u003e\n  * Replicate each database to the local app server. This has several advantages. First, we are not bound to latency anymore. Secondly, a fai\n\n* Further limitations:\n  * We are bound now to bandwidth\n  * If the remote database isn't accessible for a long period of time, we'll have an outdated database and each app has the potential to work against a different DB\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"A bit on the slow side\"\n\n\u003cdetails\u003e\n\u003csummary\u003eThe following is an improvement of the previous system design\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/remote_database_2.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n* Limitations:\n  * Queries to database might be slow, even on the server itself where the app is running\n  * Once the remote database isn't available, the local databases will not by in sync\n\n* How to improve:\u003cbr\u003e\n  \u003cimg src=\"images/design/remote_database_v2_1.png\"/\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"Always the same one\"\n\n\u003cdetails\u003e\n\u003csummary\u003eEvery request sent by the same client, is routed every time to a different web server. What problem the user might face with such design? How to fix it?\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/load_balancer/lb_sticky_sessions.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n* The problem: the user might need to authenticate every single request, because different web servers handle its requests.\n* A possible solution: use sticky sessions where the user is routed to the same instance every single time\n\n\u003cimg src=\"images/design/load_balancer/lb_sticky_sessions_fix.png\"/\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"Coming back to find we've failed\"\n\n\u003cdetails\u003e\n\u003csummary\u003eYou have a design of load balancer and a couple of web instances behind it. Sometimes the instances crash and the user report the application doesn't works for them. Name one possible way to deal with such situation.\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nOne possible way to deal with it, is by using health checks. Where an instance that doesn't pass the health check, will be excluded from the list of instances used by the load balancer to forward traffic to.\n\u003cimg src=\"images/design/load_balancer/load_balancer_health_checks.png\"/\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n#### \"In any major city, minding your own business is a science\"\n\n\u003cdetails\u003e\n\u003csummary\u003eYou have a production application using a database for reads and writes. Your organization would like to add another application to work against the same database but for analytics purposes (read only). What problem might arise from this new situation and what one improvement you can apply to the design?\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/db/analytics_application_database.png\"/\u003e\n\u003c/p\u003e\n\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nAdding another application to work against the same database can create additional load on your database which may lead to issues since the additional load might reach the limits of your database capacity constraints.\n\nOne improvement to the design could be to add a read replica instance of your database. This way the new application can work against the read replica instead of the original database. The replication will be asynchronous but in most cases, for analytics applications, that's good enough.\n\n\u003cimg src=\"images/design/db/analytics_application_database_improvement.png\"/\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n## Questions\n\nThis is a more \"simplified\" version of exercises section. No drawings, no evolving exercises, no strange exercises names, just straightforward questions, each in its own category.\n\n\u003cdetails\u003e\n\u003csummary\u003eYour website usually serves on average a dozen of users and has good CPU and RAM utilization. It suddenly becomes very popular and many users try to access your web server but they are experiencing issues, and CPU, RAM utilization seems to be on 100%. How would you describe the issue?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nScalability issue. The web server doesn't scales :'(\u003cbr\u003e\nIn order to avoid such issues, the web server has to scale based on the usage. More users -\u003e More CPU, RAM utilization -\u003e Add more resources (= scale up). An\nWhen there are less users accessing the website, scale down.\n\u003c/b\u003e\u003c/details\u003e\n\n\n\n\n### Cache\n\n\u003cdetails\u003e\n\u003csummary\u003eTell me everything you know about Cache\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eTrue or False? While caching can reduce load time, it's increasing the load on the server\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nFalse. If your server doesn't have to execute the request since the result is already in the cache, then it's actually the opposite - there is less load on the server in addition to reduced load times.\n\u003c/b\u003e\u003c/details\u003e\n\n\n### DNS\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat is a DNS?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eCan you use DNS for load balancing?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n### Storage\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat is RAID?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n### DNS\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat is CDN?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\u003c/b\u003e\u003c/details\u003e\n\n### Misc\n\n\u003cdetails\u003e\n\u003csummary\u003eHow operating systems able to run tasks simultaneously? for example, open a web browser while starting a game\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nThe CPU have multiple cores. Each task is executed by a different core.\u003cbr\u003e\nAlso, it might only appear to run simultaneously. If every process is getting CPU allocation every nanosecond, the user might think that both processes are running simultaneously.\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat is a VPS?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\n[From wikipedia](https://en.wikipedia.org/wiki/Virtual_private_server): \"A virtual private server (VPS) is a virtual machine sold as a service by an Internet hosting service.\"\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eTrue or False? VPS is basically a shared server where each user is allocated with a portion of the server OS\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nFalse. You get a private VM that no one else can or should use.\n\u003c/b\u003e\u003c/details\u003e\n\n### Distributed Systems\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat are some of the challenges one has to face when designing and managing distributed systems, but not so much when dealing with systems/services running on a single host?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nSee [Distributed Systems - Fallacies of distributed systems](#fallacies-of-distributed-systems)\n\u003c/b\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eWhat is a clock drift in regards to distributed systems?\u003c/summary\u003e\u003cbr\u003e\u003cb\u003e\n\nSee [Distributed System - Clock Drift](#clock-drift)\n\u003c/b\u003e\u003c/details\u003e\n\n## Resources\n\nThere many great resources out there to learn about system design in different ways - videos, blogs, etc. I've gathered some of them here for you\n\n### By Topic\n\n\u003cdetails\u003e\n  \u003csummary\u003eSystem Design Introduction\u003c/summary\u003e\n\n#### Articles\n* [Introduction To Systems Design - 2020](https://medium.com/swlh/introduction-to-systems-design-9bdab73fb8)\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003eScalability\u003c/summary\u003e\n\n#### Videos\n* [Harvard Scalability Lecture - 2012](https://www.youtube.com/watch?v=-W9F__D3oY4\u0026ab_channel=JorgeScott)\n\n#### Repositories\n* [awesome-scalability](https://github.com/binhnguyennus/awesome-scalability) - \"An updated and organized reading list for illustrating the patterns of scalable, reliable, and performant large-scale systems\"\n\u003c/details\u003e\n\n### By Resources Type\n\n\u003cdetails\u003e\n  \u003csummary\u003eVideos\u003c/summary\u003e\n\n#### System Design\n* [Gaurav Sen](https://www.youtube.com/watch?v=xpDnVSmNFX0\u0026list=PLMCXHnjXnTnvo6alSjVkgxV-VH6EPyvoX) - Excellent series of videos on system design topics\n* [System Design Interview](https://www.youtube.com/channel/UC9vLsnF6QPYuH51njmIooCQ) - How to get through system design interviews. Covering both architecture and code\n#### Scalability\n* [Harvard Scalability Lecture - 2012](https://www.youtube.com/watch?v=-W9F__D3oY4\u0026ab_channel=JorgeScott)\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003eRepositories\u003c/summary\u003e\n\n#### Scalability\n* [awesome-scalability](https://github.com/binhnguyennus/awesome-scalability) - \"An updated and organized reading list for illustrating the patterns of scalable, reliable, and performant large-scale systems\"\n#### System Design\n* [system-design-primer](https://github.com/donnemartin/system-design-primer) - \"Learn how to design large-scale systems. Prep for the system design interview.\"\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003eBooks\u003c/summary\u003e\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003eArticles\u003c/summary\u003e\n\n#### Introduction\n* [Introduction To Systems Design - 2020](https://medium.com/swlh/introduction-to-systems-design-9bdab73fb8)\n\u003c/details\u003e\n\n## System Designs\n\n\u003ca id=\"system-design-development\"\u003e\u003c/a\u003e\n### Development\n\nThis section focusing on the development aspect of system design (e.g. Version Control, Development Environment, etc.).\nNote: it might overlap with other sections such 'Cloud System Design'.\n\nFor each scenario try to identify the following:\n\n  * Problem Statement \u0026 Analysis\n  * Solution(s)\n\n#### Big-Scale Monorepo\n\nYou are part of a team which owns a Git monorepo. Recently this monorepo grown quite a lot and now includes hundred thousands of files. Recently, developers in your team complain it takes a lot of time to run some Git commands, especially those related to filesystem state (e.g. `git status` takes a couple of seconds or even minutes). What would you suggest the team to do?\n\n##### Big-Scale Monorepo - Problem Statement \u0026 Analysis\n\nLet's start with stating the facts:\n  * The repo has grown to include million of files\n  * It takes seconds or minutes to run Git operations while usually it takes approximately 1-2 seconds at most\n\nNext, it would be good to understand how exactly these different commands work in order to understand what we can do about the problem.\nIn case of `git status`, it runs diffs on HEAD and the index and also the index and `working directory`, to understand what is being tracked and what's not. This results in running lstat() system call which returns a struct on each file (including information like device ID, permissions, inode number, timestamp info, etc.). Running this on hundred thousands of files takes time, which explains why `git status` takes seconds, if not minutes, to run.\n\n##### Big-Scale Monorepo - Solution(s)\n\nThe solution should be focusing on how Git can perform less work in regards to its operations. In this case it's very technology specific, but there is always something to learn, even in specific implementations, on the general design approach.\n\n1. Use the built-in `fsmonitor` (filesystem monitor) of Git. With fsmonitor (which integrated with Watchman), Git spawn a daemon that will watch for any changes continuously in the working directory of your repository and will cache them . This way, when you run `git status` instead of scanning the working directory, you are using a cached state of your index.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/development/git_fsmonitor.png\"/\u003e\n\u003c/p\u003e\n\n2. Enable `feature.manyFile` with `git config feature.manyFiles true`. This does two things:\n\n  1. Sets `index.version = 4` which enables path-prefix compression in the index\n  2. Sets `core.untrackedCache=true` which by default is set to `keep`. The untracked cache is quite important concept. What it does is to record the mtime of all the files and directories in the working directory. This way, when time comes to iterate over all the files and directories, it can skip those whom mtime wasn't updated.\n\nBefore enabling it, you might want to run `git update-index --test-untracked-cache` to test it out and make sure mtime operational on your system.\n\n3. Git also has the built-in `git-maintainence` command which optimizes Git repository so it's faster to run commands like `git add` or `git fatch` and also, the git repository takes less disk space. It's recommended to run this command periodically (e.g. each day).\n\n4. Track only what is used/modified by developers - some repositories may include generated files that are required for the project to run properly (or support certain accessibility options), but not actually being modified by any way by the developers. In that case, tracking them is futile.\nIn order to avoid populating those file in the working directory, one can use the `sparse checkout` feature of Git.\n\n5. Finally, with certain build systems, you can know which files are being used/relevant exactly based on the component of the project that the developer is focusing on. This, together with the `sparse checkout` can lead to a situation where only a small subset of the files are being populated in the working directory. Making commands like `git add`, `git status`, etc. really quick\n\n\u003ca id=\"system-design-generic-systems\"\u003e\u003c/a\u003e\n### Generic Systems\n\nThis section covers system designs of different types of applications. Nothing too specific, but yet quite common in the real world as a type of application.\n\nFor each type of application we are going to mention its:\n\n  * Requirements\n  * API endpoints (public and internal)\n\n#### Payment and Reservation System for Parking Garages\n\nDesign a payment and reservation system for parking garages that supports three type of vehicles:\n\n  * regular\n  * large\n  * compact\n\nWith flat rate based on vehicle type and time\n\nNote: if you've been told to design this type of system without any other requirements, the rate and special parking, is something you should ask about.\n\n##### Payment and Reservation System for Parking Garages - Clarifications\n\nAsk clarifying questions such as:\n\n  * Who are the users and how they are going to use the system?\n  * What inputs and outputs should the system support?\n  * How much data do we expect the system to handle?\n    * How many requests per second?\n\n##### Payment and Reservation System for Parking Garages - Requirements\n\n* User to be able to reserve a parking spot and receive a ticket\n* User can't reserve a parking spot reserved by someone else\n* System to support the following types of vehicles: regular, large and compact\n* System to support flat rate based on vehicle type and time the vehicle spent in the parking\n\n##### Payment and Reservation System for Parking Garages - API (Public Endpoints)\n\n* `/reserve`\n  * Parameters: garage_id, start_time, end_time\n  * Returns: (spot_id, reservation_id)\n\n* `/cancel`\n  * Parameters: reservation_id\n\n* `/payment`\n  * Parameters: reservation_id\n  * Use existing API like Squre, PayPal, Stripe, etc.\n\n##### Payment and Reservation System for Parking Garages - API (Internal Endpoints)\n\n* `/calculate_payment` - calculate the payment for reserving a parking spot\n  * Parameters: reservation_id\n\n* `/free_spots` - get free spots where the car can park (note: small car might be able to park in bigger car spot)\n  * Parameters: garage_id, vehicle_type, time\n\n* `/allocate_spot` - do the actual reservation of a parking spot\n  * Parameters: garage_id, vehicle_type, time\n\n* `/create_account` - the ability to create an account so users can use the app and reserve parking spots\n  * Parameters: email, username, first_name (optional), last_name (optional), password (optional)\n\n* `/login`\n  * Parameters: email, username (optional), password\n\n##### Payment and Reservation System for Parking Garages - Scale\n\nWe can assume that the number of users is limited to the number of parking spots in each garage and taking into account the number of garages of course.\u003cbr\u003e\nGiven that, users scale is pretty predictable and can't reach unexpected count (assuming no new garages can be added or fixed rate of new garages being added)\n\n##### Payment and Reservation System for Parking Garages - Data Scheme\n\nSQL based database with the following tables\n\nReservations\n\n| Field       | Type                |\n| ----------- | --------------------|\n| id          | primary key, serial |\n| start       | timestamp           |\n| end         | timestamp           |\n| paid        | boolean             |\n\nGarages\n\n| Field        | Type                |\n| ------------ | --------------------|\n| id           | primary key, serial |\n| zipcode      | varchar             |\n| rate_compact | decimal             |\n| rate_compact | decimal             |\n| rate_regular | decimal             |\n| rate_large   | decimal             |\n\nSpots\n\n| Field        | Type                |\n| ------------ | --------------------|\n| id           | primary key, serial |\n| garage_id    | foreign_key, int    |\n| vehicle_type | enum                |\n| status       | enum                |\n\nUsers\n\n| Field        | Type                |\n| ------------ | --------------------|\n| id           | primary key, serial |\n| email        | varchar (SHA-256)   |\n| first_name   | varchar             |\n| last_name    | varchar             |\n\nVehicles\n\n| Field        | Type                |\n| ------------ | --------------------|\n| id           | primary key, serial |\n| license      | varchar             |\n| type         | enum                |\n\n##### Payment and Reservation System for Parking Garages - High-level architecture\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/design/apps/garage_payment_and_reservation/high_level_architecture.png\"/\u003e\n\u003c/p\u003e\n\n\u003ca id=\"system-design-real-world-systems\"\u003e\u003c/a\u003e\n### Real-World Systems\n\nThis section covers system designs of real world applications.\n\nEach section here will include full details on the system. It's recommended, as part of your learning process, that you will NOT look at these full details and start by trying figuring them out by yourself. More specifically, for every system:\n\n  * Create a list of its functional requirements, features\n  * Create a list of its non functional requirements\n  * Design API spec\n  * Perform high-level design\n  * Perform detailed design\n\n#### WhatsApp\n\n##### Features / Functional Requirements\n\n  * Messaging with individuals and groups (send and receive)\n  * Sharing documents, images, videos\n  * User status - online, last seen, etc.\n  * Message status - delivered, read (and who read it)\n  * Encryption - encrypt end-to-end communication\n\n##### Non Functional Requirements\n\n  * Scale\n  * Minimal Latency\n  * High Availability\n  * Consistency\n  * Durability\n\n##### API Spec\n\nMessaging:\n\n  * Direct Chat Session\n    * Input: API key, user ID, user ID (recipient)\n  * Send Message\n    * Input: API key, session ID, message type, message\n\nUser account:\n\n  * Register account\n    * Input: API key, user data\n  * Validate account\n    * Input: API key, user ID, validation code\n\n##### System Design Overview\n\nTODO\n\n##### System Design Components\n\nTODO\n\n#### Amazon Video Prime\n\n##### Features / Functional Requirements\n\n* Accounts\n  * Users have their account (they able to login or logout from it)\n* Uploading videos\n  * Support uploading videos (and video thumbnail) by content creators/producers\n  * Only certain accounts can upload videos not everyone\n  * Set limit for uploads\n    * Video length (e.g. 5 hours)\n    * Size per hour of video (if 5 hours and 1GB per hour = 5GB)\n    * Thumbnail size (e.g. 50 MB)\n* Streaming videos\n  * Users able to stream videos to different devices\n    * UI differ based on devices\n  * Buffering (over quality) (**Note**: A trade off)\n    * Store different quality versions of the same video\n* Browsing videos\n  * Be able to tag videos (genre, date, ...)\n  * Allow users to search for videos (based on name, tag, ...)\n\n##### Non Functional Requirements\n\n  * Reliability (Reliable video storage for storing uploaded videos and streaming them when needed)\n  * Scalability (be able to onboard users without hitting performance issues)\n  * High Availability (if one of the components fail, the system would still be usable)\n\n## System Design Process\n\nHow to perform system design?\nTODO(abregman): this section is not yet ready\n\n1. Define clearly the requirements - if requirements are not clear, make sure to clarify them\n2. Answer the question what is the projected traffic?\n3. Define which quality attributes are important for your system - scalability, efficiency, reliability, etc.\n4. TODO\n\n## System Design Interview Tips\n\nIf you are here because you have a system design interview, here are a couple of suggestions:\n\n* Choose the simplest architecture that captures the requirements (functional requirements but also expected traffic for example) of the system. No need to complicate things :)\n\nMore specific suggestions based on the phase of the interview:\n\n### What to ask yourself when you see a system design\n\nNote: You might want to ask yourself these questions also after you've done performing a system design\n\n* Does it scale if I add more users?\n* Is there a single point of failure in the design?\n* Don't be shy about asking for clarifications on a given system design. Some system design are vague on purpose\n\n### What to ask the interviewer\n\n* What are the requirements?\n  * How the system is used?\n  * How much users are expected to access the system?\n  * How often the users access the system?\n  * Where the users access the system from?\n* Are there any constraints?\n* Ask for clarifications if needed. Sometimes instructions or requirements are vague on purpose.\n\n#### What to say at the beginning of the discussion on a system design\n\n* List the required features of the system\n* State problem you expect to encounter\n* State the traffic you expect the system to handle\n\n### What you might want to state during the design or the discussion\n\n* At each decision made about the system design, state what are the cons and pros of such decision\n\n## Credits\n\nThe project banner, the icons used in \"General\" exercises section and the system design index, designed by Arie Bregman\n\n## Contributions\n\nIf you would like to contribute to the project, please read the [contribution guidelines](CONTRIBUTING.md)\n\n## License\n\n[![License: CC BY-NC-ND 3.0](https://img.shields.io/badge/License-CC%20BY--NC--ND%203.0-lightgrey.svg)](https://creativecommons.org/licenses/by-nc-nd/3.0/)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbregman-arie%2Fsystem-design-notebook","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbregman-arie%2Fsystem-design-notebook","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbregman-arie%2Fsystem-design-notebook/lists"}