System Design Diary Page 1/30- Single Server

Recently I started reading Alex Xu’s “System Design Interview”. This is not the first time starting this beginner-friendly book though, in my 3rd year while studying Software Design and Architecture course I met this book and it intrigued me quite a lot.

So I decided to start afresh, this time because I really find it fascinating to explore beyond academic syllabus and bounds. I love solving problems and that’s why it intrigues me a lot to delve into solutions that great software engineers laid down before us.

I am not here for any summary or analysis, I am here because I want to write down my own point of view, what I really got grasp of from this book, what points I could have missed and why the systems work the way they do, a kind of writing you would do to keep recording of your thought process!

Story of a single server- the building block

Let’s start with the building block of all of system design- just one server! It is not uncommon to run all of the application, business logic, database on one server especially with startups and websites having scarce userbase initially.

1. The user enters the domain name they know e.g. myportfolio.com is suppose the website’s domain name.
2. The DNS server (Domain Name System) resolves the IP address of the website from it’s domain name and gives them to the user.
3. The user communicates with the server by sending http request to it’s ip address.
4. The server returns the HTML file.

Press enter or click to view image in full size

Note that, a server is any physical or virtual machine having CPU, RAM and other computational power that can be used to serve many services at same time e.g. A server can be a physical machine running many containers in localhost like Postgresql in 5432 port, Nginx in port 80, 6379 port for Redis just like Docker engine running several containers.

Now what is the problem with this one server?

When userbase of a website grows, the server cannot keep up well with the demand. One server with its limited CPU and RAM cannot cope up with the requests during peak times. Why? Because everything eventually boils down to computational power, if we have RAM shortage it is very obvious that the servers will crash!

We separate the web server from the database server mainly for these reasons:

1. It becomes easier to scale as we separate the concerns from each other
2. It prevents resource competition as they both get their individual resources now.
3. We can easily identify the bottleneck- whether the shortage is due to database or our own web server capacity.
4. It is easier to restrict network access across different machines than different ports on same server

I tried keeping this article short because I want to deeply talk about the topics I am currently studying and we will build the blocks from bottom to top so we know why each of these system design components are needed as they are!