System Design Basics

The goal of System design is to build an end-end system, which has a lot of users, requests and data. The goal is to make a scalable, robust and performant system that is always available and reliable. 

Here are some key concepts of System Design.

> Identifying Functional and Non-Functional Requirements of a system. 

> Identifying Traffic and Memory Requirements of a System

> API calls. API design is fundamental for system design as many clients will keep calling the same API. 

> The Actual Algorithm - This is generally the actual meat of the system that is being built. 

> Database and Storage Systems. 

> DB design would include caching, in addition to permanent data storage. 

> Other Metrics: Telemetry, Performance, Security Basics. 

The goal here is to identify exactly what is the system supposed to provide from a functional perspective. Non-Functional requirements are more like Scalability, Reliability, Performance Metrics. 

This part involves figuring out the load on the system. Generally, system designs are meant to solve a big scalable problem, e.g. a whole bunch of users booking Uber, billions of people accessing Facebook at a time, etc. 

The goal is to identify: 

>  Inbound/Outbound Traffic:

- How many users we anticipate at a given time. (e.g. 500M users per month) or more

- Based on a ball park number, we can figure out requests for read and write, on a daily, yearly and a per second scenario

- Some systems are read heavy, than write heavy, so coming up with a read/write ratio, e.g. 1:100, 1:1000 will help to figure out write and read load. 

> Memory Usage: 

This is both for the persistent memory to store data as well as memory on the wire, i.e. bandwidth. For bandwidth memory, we will need /s numbers of requests, as well as the total size of a request. 

For persistent memory, the goal is to identify for how long will we hold the data. This can be 5 years for a system like an Editor, but many years for a system like Facebook etc. 

> Cache Usage: 

For most big systems, data must be held in some kind of a cache. Specific servers are needed even for this case and memory needs to be determined. The general rule of thumb is that 20% of the calls will bring in 80% of the traffic and hence they should be cached. 

The goal here is that how will the meat of the system operate. So, say the system is about url conversions, then we need to call out what logics will we use in place to actually convert those URLs. Similarly if the system is about a Facebook Messenger, the goal is to identify functional pieces that are core to chatting and storing the chat data.