QPrep- System Design Micro Experience (Crio.do)🖥💻

5 min readJun 26, 2020

(This is the part 1 of my experience for the #IBelieveinDoing challenge. Check out my part 2 QReview)

Quite frankly, the reason for me to get started with this micro-experience was System Design and things related to it. This Micro Experience helped me get started with this new fascinating world of System Design.

🏃‍♂️ Things Learnt

Host a web server in the cloud.
Host a site on a domain and understand basic protocols involved.
Configure simple Load Balancer.
Scaling a server’s performance with CDN.

Important concepts that I learned which is necessary for anyone to crack System Design interviews

Client-Server Architecture
HTTP
DNS
Load Balancing
Caching
Data Consistency

🏁 Technology Stack

Azure or GCP
Ubuntu

📌 Introduction to QPrep System Design Micro Experience

There are four modules in this micro-experience. Here is the basic architecture diagram of everything that we are going to learn in this ME:

📜 Module-wise Breakdown

Module 1: Hosting a webserver on cloud (cloud)

This module’s task was to create a Virtual Machine(VM) on either Google Cloud Platform(GCP) or Azure Cloud. I’m already a Microsoft Student Partner, so I didn’t have much confusion on what platform I should go with 😅. After that, we had to deploy and configure an NGINX HTTP server on the virtual machine.

New things we come across: Web server, VM, Azure/GCP, NGINX server, Basic commands like ping, telnet, ipconfig, etc.

Module 2: Hosting a site on a domain and understand basic protocols involved

This module’s task was to learn how HTTP works, and how we can configure the DNS server so that it points to our IP address.

We begin by purchasing an inexpensive domain. One can look at godaddy.com for cheap domains. I was lucky to have GitHub Student Developer Pack (which one can apply by visiting the GitHub site). I used name.com for purchasing a domain at no cost.

Then we had to open developer tools on our browser and play around the mysterious navigation section. Next, we have to Configure the DNS settings of our domain to point to our newly created website by adding a DNS ‘A’ record that points to our VM-address.

New things we come across: HTTP protocols, DNS server, Error Codes.

Module 3: Fun with Load Balancers

This module’s task was to configure a simple Load Balancer using DNS and understand the Load Balancing concept. A Load Balancer plays the role of a ‘traffic cop.’ It sits in front of our servers and routes client requests. This is done across all servers capable of fulfilling those requests such that speed and capacity utilization are maximized. This is helpful in ensuring that no one server is overworked, thereby taking care of optimal performance. Additionally, if a single server goes down, the Load Balancer redirects traffic to the remaining online servers. When a new server is added to the server group, the Load Balancer automatically starts to send requests to it. When a new server is added to the server group, the Load Balancer automatically starts to send requests to it.

We begin by cloning our VM, which serves as a second HTTP server. Configure the DNS load balancing of the two IP addresses from the domain by creating one more DNS ‘A’ record, which points to our cloned VM. Next, ping domain. We notice that our website is now being served either from the main VM or the Cloned VM. Even pings will resolve to different IPs at different times. This follows the concept of Round-robin scheduling algorithm. If one of our VMs goes down, our website will continue to run because of the cloned VM. This way, we learn how to achieve high availability of our service.

New things we come across: Load-Balancer, Cloning our VM, Round-robin scheduling.

Module 4: Scaling our server performance with CDN

This module’s task was understanding the performance bottleneck and Configure Content Delivery Network (CDN) to improve server performance.

We begin with choosing any free CDN provider(example: https://www.cdn77.com/). Next, we had to configure the webserver to serve a large image. We download the large image in our main directory and add it to the /var/www/html/index.nginx-debian.html. We notice that it takes more time to load the website because of the the the gigantic size of the image. Configure DNS and check the baseline performance of how much time it takes with and without the image.

By configuring CDN and setting up CDN resources, we see the difference between what happens when we serve the large image from our server and what happens when we serve the same image from the CDN provider.

The last step was to understand the eventual consistency of data like how caching works and whether the multiple sources serve the same data.

New things we come across: CDN, Caching, Data Consistency (Eventual Consistency).

👨‍🎓 Experience Gained :

Overall this was a great experience of learning. This micro-experience just got me started with the whole new world of System Designs. Special shout-out for the forum which helped me when I was stuck at any point.

A special thanks to the Crio team for the amazing workshop on System Design.

Yes #IBelieveinDoing