Web Architecture Basics in System Architecture

Web Architecture Basics Every digital interaction begins with a user action on a frontend interface, which triggers a sequence of network events that process data on backend infrastructure. Understanding web architecture requires looking at what happens during these requests and how websites are served.\ 1. The Browser Request Lifecycle When a user types a URL (like https://example.com ) into a browser address bar and hits Enter, a multi-step process takes place across the internet to fetch and render the page. THE BROWNER REQUEST LIFECYCLE ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 1. Network │ ───► │ 2. TCP & │ ───► │ 3. Backend │ ───► │ 4. Frontend │ │ DNS Lookup │ │ TLS Links │ │ Processing │ │ DOM Rendering│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ Phase 1: Network Navigation & Routing (The DNS Lookup) The browser extracts the domain name ( example.com ) and checks its local memory cache for a matching IP address. If it's a cache miss, the browser contacts a DNS Recursive Resolver . The request moves through Root, TLD, and Authoritative Nameservers to find the server's destination IP Address (e.g., 192.0.2.1 ). Phase 2: Securing the Connection (TCP & TLS Handshakes) TCP Handshake: The browser opens a reliable network lane to the server's IP address on Port 443 using the three-way handshake ( SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK ). TLS Handshake: The client and server verify SSL certificates and exchange symmetric session keys to encrypt all subsequent communication. Phase 3: Server Execution (The HTTP Request/Response) The browser constructs a formal HTTP GET Request containing headers (like browser type and language) and dispatches it over the encrypted tunnel. The request hits a reverse proxy or load balancer, which routes it to a backend application server. The server processes the request, interacts with database layers if needed, and returns an HTTP Response with a status code (like 200 OK ) and a payload (usually the raw HTML document). Phase 4: Client Display (The Rendering Pipeline) The browser parses the raw HTML text file to construct the DOM (Document Object Model) tree. As it encounters external links within the HTML, it fires off parallel requests to fetch asset dependencies like CSS stylesheets, imagery, fonts, and JavaScript bundles. The CSS engine builds the CSSOM (CSS Object Model) tree, combines it with the DOM to build a Render Tree , computes the layout position of every element, and paints the pixels onto the screen. Finally, the JavaScript engine compiles and runs scripts to make the page interactive. 2. Frontend vs. Backend Separation Modern architectures divide software applications into two distinct environments that specialize in presentation and logic. A. The Frontend (The Client-Side Layer) The frontend is everything the end-user sees, clicks, and interacts with directly inside their web browser or mobile application interface. Core Technologies: HTML5 (structure), CSS3 (styling, layout, animations), and JavaScript/TypeScript (interactivity and client-side data binding). Modern systems leverage frameworks like React, Vue, or Angular to compile structured components. Execution Environment: Runs completely inside the user's local device hardware (managed by browser engines like V8 or WebKit). Primary Focus: User experience (UX), responsive user interface design, accessibility standards, local state management, and efficient event handling. B. The Backend (The Server-Side Layer) The backend is the engine under the hood. It consists of application servers, database architectures, background workers, and message queues that power the application from behind the scenes. Core Technologies: Programming languages like Node.js, Python, Go, Java, or Ruby, paired with frameworks like Express, FastAPI, or Spring Boot. It also manages database engines (like PostgreSQL, MongoDB, or Redis). Execution Environment: Runs inside centralized cloud infrastructure , virtual machines, or server containers unexposed to the open internet. Primary Focus: Business logic execution, secure data persistence, access controls, performance optimization, and API endpoint exposure. 3. Static vs. Dynamic Websites The choice between a static or dynamic setup dictates how web servers generate and deliver assets to the client browser. STATIC VS. DYNAMIC ASSET DELIVERY STATIC WEBSITES (Pre-Rendered Edge Delivery) [Client Browser] ◄─────────────── (Direct Raw File) ─────────────── [CDN Edge Node] DYNAMIC WEBSITES (Runtime Server Generation) [Client Browser] ◄─── (Assembled HTML) ─── [App Server] ◄─── (Data) ─── [Database] A. Static Websites (Pre-Rendered Delivery) In a static website architecture, every single web page is fully pre-built and saved as a raw file (HTML, CSS, JS) on a storage drive before any user makes a request. Delivery Mechanics: When a client requests a page, the web server or CDN edge node does zero computing work. It simply reads the static file directly from storage and transfers it straight down the wire to the browser. Every user requesting that URL receives the exact same file. Core Advantages: High Speed: Near-instant delivery times because there are no server-side scripts or database queries to run. Simple Scalability: Static files can be cached globally across CDN points of presence, removing the risk of server overloads during traffic spikes. When to Use: Corporate homepages, public product documentation sites, personal blogs, or marketing landing pages where content changes infrequently. B. Dynamic Websites (Runtime Assembly) In a dynamic website architecture, pages do not exist as pre-built files on disk. Instead, pages are generated on the fly at runtime by a server whenever a request arrives. Delivery Mechanics: When a user hits a dynamic URL, a backend application server catches the request, runs business logic rules, queries relational databases or caches to pull fresh data, injects that data into a layout template, and assembles the final HTML file to return to the user. Alternatively, it serves a generic frontend single-page application wrapper that pulls raw data via JSON APIs at runtime. Core Advantages: Personalized Content: The page can display unique content customized for the logged-in user, their geographic location, or their real-time permissions. Live Data Updates: Content changes instantly the moment an internal database record updates, with no need to rebuild or redeploy static files. When to Use: E-commerce platforms with live inventory, social networks, real-time dashboards, banking services, or any platform requiring user accounts and interactive data processing. Web Architecture Foundations Reference Matrix Architectural Variant Primary Hosting Infrastructure Runtime Compilation Location Asset Delivery Velocity Functional Use Case Profile Static Setup Object Storage Buckets (e.g., AWS S3) linked to global CDN edge nodes. Pre-compiled during the initial build pipeline before deployment. Ultra-fast (Measured in milliseconds directly at the network edge). Marketing sites, blogs, open documentation, and landing pages. Dynamic Setup Compute Clusters (e.g., AWS EC2, Kubernetes) linked to live databases. Generated at runtime on the backend application server per request. Variable (Dependent on database query optimization and network latency). SaaS portals, banking applications, social networks, and live dashboards.