Web Architecture 101

Browser Client

Browser makes a request for the files to build out the website
The request goes to a server that holds all of those files that allow you to build that website
The server sends a response with the appopriate JS, HTML, CSS files
This does not scale well, so you need more things to scale

DNS: Domain Name System
A unique name that is human readable
The name maps to an IP address (unique address on the web)
Each website has its own unique IP address
Big websites have hundreds of thousands, if not millions of IP addresses, for each web server.
A website can own many IP addresses, each of them unique.
The DNS figures out what specific IP address you need.
(Old) IPv4: 59.53.187.13 (4.29 x 10^9 amount of bits)
(New) IPv6: 2a03:2880:012:1: face:b00c::1 (3.4 x 10^38 bits) - significantly larger
The request itself might ask for a specific format of IP address
Figures out based on your location and different factors, etc.

Server that accepts requests and sends the corresponding files
As a client, you keep sending network requests to a web server to fetch different parts of the website
Client uses JSON/other response to build the content in a specific format
Web server has:
- Application logic: Code you are writing as a developer, apply some transformation steps to some specific data
- Database: Hold data in a specific format
Web Server is under tremendous load for serving requests
Scale in two ways:
- Vertical Scaling: Add more resources to one server
- Horizontal Scaling: Add more servers/instances

We duplicate the web server to duplicate application logic, but should we duplicate the database? Probably not
Web servers are cloned and interact with the same (one) database
Assumptions to understand load balancing:
- All requests have the same latency (time to fire requests and get back response)
- All servers have identical resources
How do you manage the vast number of requests coming in, even with multiple servers?
Therefore, we need a load balancer otherwise servers will go down
The sole purpose of a load balancer is to evenly distribute the load, acting as an entrypoint. Communicate from browser to the load balancer
In real requests, different requests take different times so load balancer has to distribute the load smartly.
One basic strategy is Round Robin. We go in order of the list of servers we have access to. Just move from one server to another. In real life, this might not be the most efficient load balancing strategy.

Need to maintain a continuous connection with your client and server because you are using the app. You are constantly making requests to receive new data specific to the session you have
You cannot jump between multiple servers, and one client. The Web server is the only one aware of what it has given to the user so far
In certain applications where we need session persistence, this may be necessary.
If a server goes down, some other server does some compute to figure out where the session was left off, and catches up to what's happened.

A caching service prioritizes speed of retrieval over amount of data storage
It's designed to store significantly less data
In your system design, you are doing so with the decision of storing high-impact data that you are pulling out, fast
Very useful for repetitive region-specific data, etc.
Repetitive data is cached for faster access

Business Logic is basically:
- some computation that the client is asking for
- Code that delivers a functionality specific to the business (user)
- Any logic that drives some outcome based on user's expectations or interactions
Everything else is Application Logic:
- For example API calls in the background
- Written application logic or code that queries data sources, etc.
Job servers step in and perform that activity
A Job is a computational unit of work for our application to have the appropriate functionality or data
Job Servers fetch jobs from the Job Queue

Way to understand how job servers know when to perform these Jobs
Queue refers to the Data Structure, FIFO (First-in, First-out)
Job Queue is a Priority Queue that has:
- Higher Priority > Lower Priority
- FIFO
Web Servers also have Cron jobs, i.e they queue and figure out when to start setting up these jobs
Cron Jobs are just jobs that run based on your command for it at some specific time

A lot of what we build are services
Services encapsulate all of the components that we design in systems, but as a service
An app can have a multi-service architecture, for example: Authentication service, Messaging service, Newsfeed, Communities etc.
Each of them can be their own independent system or service
A service is a self-contained deliverable system - it does one thing really well

This service receives requests to Get Posts
- Hits Load Balancer
- which hits Web Servers,
- which fetch authentication data from Database
This is rudimentary 1-Factor Authentication

Data Hose and Data Warehouse
To collect data, you have these data services
The raw data gets passed to the Data Hose, which gets passed to the Data Warehouse - it can be through the web server or on the client itself
The Data Hose will process that data and send it to the Data Warehouse
The Data Hose is the entry point

Cloud Storage is a backup source of data
You can do most of this diagram on cloud providers such as AWS, Azure, GCP, etc.
CDN is Content Delivery Network
It makes it more performant for us to deliver our content to users all around the world
You can store the website files in the CDN, so the browser doesn't have to go to the web server to load the website
Drastically reduces latency
Edge Servers are localized servers that live around the world
The CDN figures out the nearest edge server, which receives the request instead
You have to figure out when to make your changes from origin server to edge servers, so there is a consideration to make when using CDNs
Makes sense for large distributed systems with global usage

Last updated 1 year ago