snomad1 / system-design-notebook Goto Github PK

A curated collection of resources and exercises to help you learn about system design

• Topics
• Topics Explained
• Exercises
• Questions
• Resources
• System Design Process
• Interview Tips
• Q&A

• Requirements
  • Functional Requirements
  • Non-Functional Requirements
• Basic architecture
  • Client
  • Server
  • Dispatcher
• Scalability
  • Vertical Scaling
  • Horizontal Scaling
  • Scalability Factor
    • Linear Scalability
    • Sub-linear scalability
    • supra-linear scalability
    • Negative scalability
• Availability
• Performance
• Resiliency
• Microservices Architecture
• Monolith Architecture
• Cache
  • Distributed Cache
  • Cache Policy (aka Replacement Policy)
    • LRU (least recently used)
• Load Balancing
  • Consistent Hashing
  • Techniques
    • Round Robin
    • Weighted Round Robin
    • Least Connection
    • Weighted Least Connection
    • Resource Based
    • Fixed Weighting
    • Weighted Response Time
    • Source IP Hash
    • URL Hash
• Fault Tolerance
• Distributed System
• Extensibility
• Loose Coupling
• Proxy
• Storage
  • RAID
• CDN
• DNS
• Networking
  • IP
    • Private IP
    • Public IP
  • Latency
  • Throughput
• Design Level
  • Low level design
  • High level design

Usually a system design process starts with understanding the system's purpose and one way to understand system's purpose or goal, is to clearly define a list of requirements.
These requirements allow us not only to understand how the system will be used and how it works, but also set clear boundaries which will make sure our design is focused on the right aspects of the systems. We usually distinguish between functional and non-functional requirements.

Functional requirements are used to specify an expected function or a behaviour of the system. Simply put, something the system should be able to do.
For example, for a video streaming service a requirement might be to upload a video or comment on a video. For instant messaging application, a functional requirement will be, to be able send and receive messages.

Non-functional requirements focus on how the system performs, especially in general and not focusing on specific functions.
While such requirements might affect user's experience they shouldn't affect specific functionality or features the system supports.

For example, if a system is a type of a service, a non-functional requirement might be "zero downtime" or "No loss of data".

A client refers to a software or hardware accessing a resource or a service that is served by a server. While in some cases the server and the client might be on the same system/host, in most cases they will be on separate systems.

Examples for clients:

• A Web browser that is used by a user to access a certain web page
• A mobile phone that is used by the user to read emails

A server, similarly to a client, can be a software or hardware, but as opposed to a client, its role is to serve the client. It can be by providing a certain resource to the client or let it use a service that is running on the server. Few examples:

• A system that stores files and allow the user to access or download them
• A system that runs a service which allows users to listen to music

Wikipedia: "Scalability is the property of a system to handle a growing amount of work by adding resources to the system"

In simpler words, scalability is about answering the question whether a system or an architecture are able to scale in a way that meets the new workloads and demand.
More practically, answer questions like:

• if a system runs a database, does it able to handle more queries?
• if a system runs a service that stream videos to million users. Will it able to stream them the same way if the amount of users would triple itself?

Also, scaling can be performed on different components. For example, in most cloud environments scaling is supported in case of:

• Compute hosts
• Virtual network functions
• VMs/Instances
• Containers

There are different ways to scale.

Adding additional resources to the existing system/component/unit. If we have a server, a vertical scaling might be done in one or more of the following ways:

• Adding more RAM to the server
• Adding more storage/disks
• Adding CPUs

Adding more systems/units/components but at the same time, make them work together so it would seems to the client as if there is one system it interacts with.
Few examples:

• Instead of one web server, having two web servers with one load balancer balancing the traffic between them
• Instead of one database server, having two databases

When you double the resources of your system (or design) you might expect your system to be able to handle double the workload as well, right? But this is not necessarily what will happen. Scalability factor is the term used to describe the workload your system is able to handle as a result of scaling your resources.

Linear Scalability happens when the workloads your system is able to handle scale accordingly to the scale in resources. The scalability factor remains constant as you scale.
For example, you triple the resources of your system -> the system is able to handle triple the workloads. In reality, it's actually not the case most of the time.

A more realistic outcome of scaling systems would be that some resources or component may not scale as expected (or as other resources and components). So doubling the resources will actually lead to an improvement of only x1.5 in workloads handling. In this case the scalability factor will be lower than 1.0

This is the optimal outcome. You triple the workloads handling by "only" doubling your resources for example. In other words, the ratio in performance change is bigger than the ratio in scaling changes (e.g. adding more CPUs). A scalability factor in this case, is bigger than 1.0

It may sound crazy, but in some cases, scaling your system might actually lead to worse results and that's exactly what negative scalability is all about. Scalability factor is below 0.

Wikipedia: "A public IP address, in common parlance, is a globally routable unicast IP address, meaning that the address is not an address reserved for use in private networks"

From system design perspective, when you have a resources or a component, you would like everyone to be able to access to, whether for direct communication (like a web server) or as a gateway for other components (like a load balancer), you should use a public IP

Whenever you don't want users to be able to globally interact with a certain component or resource, you should use a private IP address. Few examples:

• Web servers that only the load balancer should communicate with them directly
• Internal servers that users outside the organization should access

Private IPs, as opposed to public IPs, don't have to be unique and each separate network, can use the same addresses.

The time it takes to perform a certain task/action

The number of tasks/actions per unit of time

Wikipedia: "Most prominently, it translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols."

In other words, the most common use can of a DNS would be a address translation. It can be from a hostname to IP address and vice versa - from an IP address to a hostname. In addition, a DNS can be used for load balancing, using the round robin technique.

Cloudflare: "A content delivery network (CDN) refers to a geographically distributed group of servers which work together to provide fast delivery of Internet content."

In other words, a content delivery network allows you to quickly transfer content by having servers with the content around the world or certain area. The client then, access these servers instead of the main server where the data originates from.

Note: The names of the exercises are quotes from movies (sometimes little bit modified). If you can guess from which movie, please submit it to movies.md file in this way: [QUOTE] [MOVIE] [YOUR NAME]
Another note: Exercises may repeat themselves in different variations to practice and emphasize different concepts.

This 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.

There 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

How to perform system design???

1. Define which quality attributes are important for your system - scalability, efficiency, reliability, etc.

If you are here because you have an system design interview, here a couple of suggestions

Note: You might want to ask yourself these questions also after you've done performing a system design

• Does it scale if I add more users?
• Is there a single point of failure in the design?

• What are the requirements?

  • How the system is used?
  • How much users are expected to access the system?
  • How often the users access the system?
  • Where the users access the system from?

• Are there any constraints?

If you would like to contribute to the project, please read the contribution guidelines