System Design Fundamentals Part I

the system basics that developer should know

As a developer, my journey has always been fueled by a passion for crafting systems that are not just functional, but also scalable, efficient, and robust. Whether diving into Low-Level Design (LLD) or High-Level Design (HLD), the challenge is always thrilling.

System design is challenging. Trade offs have to be made on a case to case basis. There are certain basic concepts without which designing a system will become more challenging. In the end or throughout the development cycle you may encounter the need of redesigning or code refactoring if it is not properly analysed, designed with considerable trade offs and developed according to the design. If you want to acquire system design skill set, you need to know those fundamental concepts of a software system.

This article is your gateway to understanding these key concepts. We’ll start with some basics and gradually explore more complex topics in future articles.

So, why to wait! Let’s start.

In today’s internet era, terms like link, url, website, host and server etc. are part of our everyday vocabulary. A link or URL acts as the digital address for a website. Websites are hosted on servers, essentially powerful computers that store and serve these sites. But how do these connections work? How does your computer find and display a website from a server located potentially thousands of miles away? This is where the intriguing concept of DNS (Domain Name System) comes into play. If DNS is still a mystery to you, you are at the right place. It’s the time to resolve this puzzle.

Domain Name System (DNS)

When you try to access any website from a browser, you must have typed a URL e.g. “https://www.google.com” on the browser and pressed “Enter” (in case of windows) or “return” (in case of mac) and saw a web page loaded on the browser. Let’s try to understand what has happened in the journey of the page getting loaded on your screen, refer fig-1.1

fig-1.1

1. URL Entry: When you enter a URL like “https://www.google.com" in your browser, you’re using a domain name (here, “www.google.com") to start your internet journey.
2. DNS Lookup: This URL request is sent to a DNS server, a service often provided by third parties. The DNS translates the domain name into an IP address.
3. Receiving IP Address: The DNS server returns the IP address of the website, like “103.5.135.70”, to your browser.
4. HTTP Request: Your browser then sends an HTTP request to the web server at this IP address, asking for the webpage.
5. Server Response: The server responds by sending back the requested webpage, often in formats like HTML, JSON, or XML, which your browser then displays.

In this example, web application and mobile application are responsible for rendering of the view.

Let’s go a bit deeper for DNS Lookup. DNS Lookup is not s single step task. There are couple of further concepts. Let us see what are those -

DNS Records: These are the rules stored within DNS servers. They include various types of data, such as A records (which link domain names to IP addresses) and MX records (which specify mail servers for a domain).

• A Record (Address Record): This record links a domain name to its corresponding IPv4 address. It’s crucial for directing internet traffic to the correct location.
• AAAA Record: Similar to the A Record, but it links the domain name to an IPv6 address, which is a newer, longer IP address format.
• CNAME Record (Canonical Name Record): This record allows you to alias one domain name to another. It’s useful for linking subdomains to the primary domain.
• MX Record (Mail Exchange Record): Specifies the mail servers responsible for handling emails for your domain, vital for routing email communications.
• TXT Record: Used for various text-based information like SPF data (Sender Policy Framework) to help with email spam prevention.
• NS Record (Name Server Record): Points to the servers that contain authoritative DNS records for the domain, essentially telling the internet where to find the domain’s DNS details.

Name Servers: These servers store DNS records and respond to queries about domain names and their associated IP addresses.

Root Servers: These are the highest-level DNS servers that guide the DNS lookup process towards specific, lower-level name servers.

TLD (Top-Level Domain) Servers: These servers store information about domains under a specific top-level domain (like .com, .net, .org).

Recursive Resolver: This is an intermediary server that receives queries from browsers and then makes a series of requests to other DNS servers to find the correct IP address.

fig-1.2

This figure explains the DNS lookup step.

Assume you’ve developed a web application and deployed it on your personal laptop, which is connected to the internet. You’ve determined your laptop’s public IP address and purchased a domain name, say “myfirstproject.com,” from a domain provider. On the provider’s platform, you’ve configured the DNS settings so that any requests to your domain are directed to your laptop’s IP address.

This setup should work fine under normal circumstances. However, it has a critical dependency on the stability and consistency of your laptop’s public IP address. In events like a system crash, power outage, or internet reconnection, your laptop may acquire a new public IP address upon restarting. Since your domain’s DNS settings still point to the old IP address, users attempting to access your web application will not reach it.

To resolve this, you’d need to manually update the DNS records with the new IP address every time it changes. This makes the setup impractical for a reliable, publicly accessible web application. It underscores the importance of using stable, dedicated hosting environments for web applications, especially for public access.

fig-1.3

Let us summarise the problems of this single server setup -

1. Server Outage and Unavailability: If the laptop (acting as the server) faces network issues, power outages, or hardware failures, the entire website becomes unreachable. There’s no failover system in place to keep the site running.
2. Dynamic IP Address Issue: Most personal internet connections use dynamic IP addresses, which change upon network reconnection or system restarts. This necessitates frequent updates to the DNS settings, which is impractical for a stable web service.
3. Security Risks with Public IP Exposure: Exposing your laptop’s public IP can be a security risk. While public IPs themselves are not inherently insecure, the lack of robust security measures typically present in personal systems can make your setup more vulnerable to attacks.
4. Vulnerability to DDoS Attacks: A single server setup, especially on a less powerful machine like a laptop, is highly susceptible to DDoS attacks. These can easily overwhelm your server’s capacity, leading to service disruptions.
5. Inability to Handle High Traffic: A personal laptop serving as a web server will likely have limited resources and cannot scale to handle sudden spikes in traffic. This can result in the website becoming slow or entirely unresponsive under heavy load.

This is where load balancer comes into picture.

Load Balancer

A load balancer can redirect requests to a set of web servers. It communicates through private IPs with the servers. It will always have the same IP address assigned. Let’s try to understand with the help of fig 1.4

fig-1.4

In the scenario depicted in fig-1.4, the original single laptop server setup is upgraded by replacing the laptop with a dedicated web server and adding an additional server for redundancy. A load balancer is introduced to manage traffic between these servers.

The load balancer acts as a traffic director, distributing incoming requests across the two servers. It communicates with each server using private IP addresses and maintains a constant public IP address for external access. This setup enhances the system in several ways:

1. Improved Failover: If Server 1 encounters issues and goes offline, the load balancer automatically redirects all traffic to Server 2. This redundancy prevents the website from becoming unreachable, ensuring continuous availability.
2. Scalability: In case of a surge in traffic or if the existing servers are insufficient, an additional server can be seamlessly integrated into the system. The load balancer will start diverting some of the traffic to this new server, balancing the load among all active servers.
3. Enhanced Availability: With multiple servers in place, the risk of a complete service outage is significantly reduced. The load balancer ensures that even if one server fails, the others can continue to provide uninterrupted service.

This multi-server and load balancer arrangement effectively resolves the issues of limited capacity, lack of failover, and risk of downtime associated with a single-server setup. It provides a more reliable and scalable solution for hosting web applications.

You’ve just navigated a wealth of information, so let’s take a moment to breathe and reflect on all that we’ve explored together. Remember, this is just the beginning!

As promised, I’m already gearing up for “Part II” of our System Design Fundamentals series. So, stay curious, keep those gears turning, and follow me for more upcoming insights. Until next time, stay tuned!!!