Day 1 A-Foundations 2026-09-29 ← All lessons

From one server to a website: DNS, web tier, database

Every large system starts as a single server. The first real step is splitting the web tier from the data tier so each can scale on its own.

15.125.23.214Example IP address returned by DNS for api.mysite.com
40 yearsRelational databases have been around for over 40 years
24 TBMaximum RAM available on a single Amazon RDS database server
10 millionMonthly unique visitors on stackoverflow.com in 2013 with only 1 master database

Key points

Outcomes

01Trace the request flow from a user typing a domain name to receiving an HTML page or JSON response.
02Explain why separating web and data tiers enables independent scaling.
03Decide between relational and non-relational databases based on application requirements.
01

Request flow: from domain name to web server


  1. User enters a domain name like api.mysite.com in the browser or mobile app.

  2. DNS resolves the domain name to an IP address, for example 15.125.23.214.

  3. The browser or mobile app sends an HTTP request directly to that IP address.

  4. The web server returns an HTML page or a JSON response for rendering.

Interview tipDNS is usually a paid service provided by third parties and is not hosted on your own servers.
02

Web tier and data tier: why split them?


With growth, one server is not enough. You need multiple servers: one for web and mobile traffic, another for the database. Separating the web tier from the data tier allows them to be scaled independently.

How to read: Follow arrows left to right: users reach the load balancer, which routes to web servers, which read and write to the database.

flowchart LR U[User] --> DNS[DNS] DNS -->|IP address| LB[Load balancer] LB --> WS1[Web server 1] LB --> WS2[Web server 2] WS1 -->|read/write/update| DB[(Database)] WS2 -->|read/write/update| DB DB -->|return data| WS1 DB -->|return data| WS2
Web tier and data tier separated, with a load balancer distributing traffic to multiple web servers.
03

Which database? Relational vs non-relational


Option A

Relational (SQL)

  • Stores data in tables and rows
  • Supports join operations across tables using SQL
  • Popular examples: MySQL, Oracle, PostgreSQL
  • Best option for most developers due to 40+ years of proven use
Option B

Non-relational (NoSQL)

  • Grouped into key-value, graph, column, and document stores
  • Join operations are generally not supported
  • Popular examples: CouchDB, Neo4j, Cassandra, HBase, DynamoDB
  • Choose when you need super-low latency, unstructured data, or massive scale
NoteNon-relational databases might be the right choice if your application requires super-low latency, your data is unstructured, you only need to serialize and deserialize data (JSON, XML, YAML), or you need to store a massive amount of data.
Q&A

Check yourself


Q1What is the main reason to separate the web tier from the data tier?
  • To reduce the cost of DNS
  • To allow each tier to be scaled independently
  • To eliminate the need for a load balancer
✓ To allow each tier to be scaled independently — Separating web and data tiers lets you scale each independently as traffic and data grow.
Q2Which of the following is NOT a reason to choose a non-relational database?
  • You need super-low latency
  • Your data is unstructured
  • You need complex join operations across tables
✓ You need complex join operations across tables — Non-relational databases generally do not support join operations; relational databases are better for that.
Q3What does DNS return to the browser or mobile app?
  • An HTML page
  • An IP address
  • A JSON response
✓ An IP address — DNS resolves a domain name to an IP address, which the client then uses to send HTTP requests.
Sources: System Design Interview, Ch. 1, Single server setup, Database, Which databases to use? (pp. 1–10)