System Design Book Summary

This blog is the summary of system design book by bytebytego, we would explore how to build a system that can scale from zero to millions of users without breaking down completely.

Setting a Single Server

Climbing a peak starts with taking your first step. So just getting started with a yanky system is the best we can do. We would be running everything on a single server from web app, database, cache or whatever as given below.

Request Flow

• ▸Users access the websites, via browser or mobile apps, using domain names like google.com which are paid and given by DNS providers.
• ▸When we enters the domain address, request is sent to DNS providers and corresponding IP address is returned back to the browser.
• ▸Now, HTTP requests are sent using IP address directly with web server which returns HTML or JSON response for rendering.

Traffic

Web apps and mobile are two main sources to drive traffic with web web servers.

Database

As no. of users grow, handling everything with single servers gets hard so we uses multiple servers, web tier for traffic and data tier for database storage which can scale independently.

• ▸We can use Relational or Non-relational databases based on needs and requirements.
• ▸In Relational DBs we can perform JOIN operations but same is not true for other.
• ▸In RDBMS, data is stored in tables and rows.
• ▸Non-RDMBS are grouped as key-value store, graph stores, column stores and document stores.

Vertical Scaling and Horizontal Scaling

Vertical Scaling is increasing the size the size or capacity of a single server or store. Horizontal Scaling is increasing the no. of servers and stores. Generally Scaling Horizontally is preferred to tackle uncertinities and failures as keeping all the eggs in the same basket could led to huge loss. Also Scaling Vertically is costly and high risk prone.

Load Balancer

LB evenly distributes the incoming traffic among available servers. Every Load Balancer has a Public IP which we use to send requests and web servers has private IP, so LB is acting like a gateway, servers become unreachable directly from internet. LB takes the request and pass it to an approprite web server. It also helps during failover like if one server goes down then all the requests are sent to other servers and whole system stays intact without getting affected, so it removes that single point of failure we had while putting everything in a single server. During high traffic hours, new servers would be up and down during low traffic.

Database Replication

It is basically keeping the same data in multiples database. We generally uses master-slave architecture in which there is a master server where we only write data and no read operations are done, and other one is slave servers which copies data from master DB and keeps the copies which we uses for reading operations. We can have multiple such slave DBs so when one goes down whole system still stays intact. When Master server goes down we makes a slave server the temporary master though it's complex process, it's not easy to take place of master.

Cache

It is a temporary storage we uses to store frequent accessed data because making DB calls are expensive and we wants to minimize the no. of DB calls we make.

Cache tier

We places a middle layer between database and API, so our requests goes to cache checks if the data is there, request is directed from cache to DB and content is requested and stored cache store and from there passed to the server. It reduces the total no. of calls we make and makes the overall application efficient and fast.

When to use Cache?

• ▸Some data is being used Frequently
• ▸Expiration Policy, should have a good expiration time as give less time and it's useless, give lots of time and data becomes stale.
• ▸cache data should be as consistent as possible with the database.
• ▸also mainting multiple cache stores is advisable for tacking single point of failure issue.

CDN

Content Delivery Network(CDN) is a network of servers or stores spread across world which serves static content.

How it works?

When user requests, CDN nearby delivers the content, if it's not there, it request to the origin and gets back the content and then deliver it the user and caches the data, so next time fast retrivel is possible for similar data, which ultimately reduces load times.

Current Architecture Design

To be continued...