One Physicist, Three Protocols, and the Internet You Know
In March 1989, Tim Berners-Lee submitted a proposal to CERN management titled 'Information Management: A Proposal.' His boss wrote 'vague but exciting' on the cover page and let him continue. The physicist was trying to solve a coordination problem at a particle physics lab, and the groundwork he laid would eventually shape the three-tier architecture that nearly every web application still follows today. Instead, he accidentally invented the platform for global commerce, social networking, streaming video, and the entire modern software industry.
Berners-Lee built three things: HTML (a way to format documents with links), HTTP (a protocol to transfer them over a network), and URLs (a universal addressing scheme). He explicitly chose not to patent any of it. Within five years the web exploded from a physics lab curiosity to a global platform with millions of users. Every system design question you will ever face exists because one physicist in Geneva decided to give away his invention.
HTTP and the Statelessness Problem
HTTP was designed as a stateless protocol. Each request is independent. The server responds and immediately forgets the client ever existed. This made HTTP simple and scalable, which was the right decision for Berners-Lee's document-sharing use case. But real applications need state. Shopping carts need to remember what you put in them. Authentication needs to remember you logged in. Social networks need to know who you are.
This tension between HTTP's statelessness and the need for stateful applications drove decades of engineering. Cookies, sessions, JWTs, OAuth tokens. All of these are solutions to the same underlying problem: how do you maintain state across stateless requests? When an interviewer asks you to design an authentication system, they are really asking you to solve a problem created by the HTTP design decision made in 1989.
The Three-Tier Architecture (1995)
As web traffic grew, the industry settled on a pattern so natural it became invisible. The presentation tier (browser or mobile app) handles what users see. The logic tier (application servers) handles what the application does. The data tier (database) handles what gets stored. Three layers, clean separation of concerns, and each tier could be scaled independently in theory.
Every web framework ever built assumes this model. PHP, Rails, Django, Spring Boot, Express. They are all packaging the same three-tier pattern into a developer-friendly form. This architecture dominated the web for a decade and still describes the vast majority of applications running today.
Three-tier architecture is the starting point of every system design interview, whether you draw it or not. The question is never whether to start there. The question is where it breaks and what you do about it.
Where Three-Tier Breaks Down
The three-tier model has a critical weakness: the database is a single point of failure, and it is the hardest tier to scale. Adding more application servers is straightforward, you put a load balancer in front and spin up more instances. Adding more database capacity is not. You cannot just add a second database server without coordination logic. Who handles writes? How do reads stay consistent? What happens during failover?
In the mid-1990s, this ceiling was high enough that most applications never hit it. Then sites like Amazon, eBay, and Yahoo started seeing tens of millions of daily users. Vertical scaling (buying bigger and bigger database servers) hit physical limits and cost ceilings. The three-tier model that had served the industry well started cracking. The next 25 years of system design is the story of breaking apart the three-tier model, piece by piece, to handle scales its inventors never imagined.
Problem 1: Single database server is a single point of failure and a scaling bottleneck
Problem 2: Application servers are stateless but the session data needs to live somewhere shared
Problem 3: All tiers must be deployed together, slowing release cycles
Problem 4: A slow or buggy logic tier takes down the entire user experience
What This Means for System Design Interviews
The interviewer who asks you to 'design Instagram' or 'design a URL shortener' is watching to see whether you understand the three-tier model and, more importantly, where it fails. Starting with a basic web server and database is correct. Then your job is to show you understand the failure modes: database becomes a bottleneck, add read replicas. Traffic spikes take down the whole app, add caching. Single region goes down, add geographic distribution. The three-tier model is the foundation. Knowing how to evolve it beyond that foundation is the interview.
Further Reading
Tim Berners-Lee's original 1989 proposal, available online at info.cern.ch
Roy Fielding's PhD dissertation (2000): 'Architectural Styles and the Design of Network-based Software Architectures', which formalized REST
Alex Xu's 'System Design Interview' Vol 1, Chapter 1 for the canonical three-tier scaling walkthrough
HTTP's Evolution: Why the Protocol Kept Changing
HTTP/1.0 (1996) opened a new TCP connection for every request. A page with 5 images required 6 TCP handshakes and 6 TLS negotiations. At slow modem speeds this was tolerable. At broadband speeds with 200 assets per modern page, it was catastrophic. HTTP/1.1 fixed this with persistent connections (keep-alive) and pipelining, but pipelining had a head-of-line blocking problem: a slow response blocked all queued requests behind it. HTTP/2 (2015) solved this with binary framing and full request multiplexing over a single TCP connection, plus header compression (HPACK). HTTP/3 (2022) replaced TCP itself with QUIC, eliminating TCP's inherent head-of-line blocking at the transport layer.
HTTP/1.0: one TCP connection per request. Simple, but slow for asset-heavy pages.
HTTP/1.1: persistent connections, pipelining, chunked transfer encoding, Host header enabling virtual hosting.
HTTP/2: binary framing, stream multiplexing (multiple requests in parallel on one connection), server push, HPACK compression.
HTTP/3: QUIC transport (UDP-based with reliability), eliminates TCP head-of-line blocking, faster connection establishment with 0-RTT.
TLS 1.3 (2018): reduced handshake to 1-RTT from 2-RTT, 0-RTT session resumption. Security improvement with performance gains.
Evolving Past Three-Tier: The Natural Scaling Progression
Every production system outgrows the basic three-tier model in the same sequence. First the database becomes slow: add a caching layer (Redis/Memcached) for hot reads. Then the database cannot handle the write volume: add read replicas, split reads and writes. Then the single application server cannot handle traffic: add horizontal scaling behind a load balancer. Then different parts of the application have different scaling needs: extract high-traffic or CPU-intensive components as separate services. This is not microservices dogma. It is pragmatic evolution driven by actual bottlenecks.
Step 1: Vertical scaling - bigger database server. Fast to implement, limited ceiling, expensive.
Step 2: Read replicas - route read queries to replicas, writes go to primary. Adds complexity around replication lag.
Step 3: Caching layer - Redis or Memcached in front of the database. Cache-aside, write-through, or write-behind patterns.
Step 4: CDN for static assets - remove static file serving entirely from your application tier.
Step 5: Application tier horizontal scaling - multiple app servers behind a load balancer. Requires stateless applications.
Step 6: Database sharding or switching to a distributed database for write-heavy workloads.
What Interviewers Test About Three-Tier and HTTP
System design interviews almost always start with a three-tier setup and then probe how you evolve it. The interviewer wants to see that you know the failure modes of each tier and the specific tools/patterns that address each failure. Vague answers ('add more servers') are less valuable than specific answers ('add read replicas and route read traffic with a load balancer, accepting up to 100ms replication lag for non-critical reads'). HTTP knowledge shows up in API design questions, caching questions, and CDN questions.
Know: the difference between stateless and stateful application servers, and why stateless enables horizontal scaling
Know: HTTP caching headers (Cache-Control, ETag, Last-Modified) and how they interact with CDNs
Know: connection pooling between the app tier and database tier, and why max_connections is a database bottleneck
Know: when to use a reverse proxy (nginx/HAProxy) versus a cloud load balancer (ALB/ELB)
Know: the N+1 query problem and how ORMs cause it, with solutions (eager loading, DataLoader pattern)
HTTP's Evolution: Why the Protocol Kept Changing
HTTP/1.0 (1996) opened a new TCP connection for every request. A page with 5 images required 6 TCP handshakes and 6 TLS negotiations. At slow modem speeds this was tolerable. At broadband speeds with 200 assets per modern page, it was catastrophic. HTTP/1.1 fixed this with persistent connections (keep-alive) and pipelining, but pipelining had a head-of-line blocking problem: a slow response blocked all queued requests behind it. HTTP/2 (2015) solved this with binary framing and full request multiplexing over a single TCP connection, plus header compression (HPACK). HTTP/3 (2022) replaced TCP itself with QUIC, eliminating TCP's inherent head-of-line blocking at the transport layer.
HTTP/1.0: one TCP connection per request. Simple, but slow for asset-heavy pages.
HTTP/1.1: persistent connections, pipelining, chunked transfer encoding, Host header enabling virtual hosting.
HTTP/2: binary framing, stream multiplexing (multiple requests in parallel on one connection), server push, HPACK compression.
HTTP/3: QUIC transport (UDP-based with reliability), eliminates TCP head-of-line blocking, faster connection establishment with 0-RTT.
TLS 1.3 (2018): reduced handshake to 1-RTT from 2-RTT, 0-RTT session resumption. Security improvement with performance gains.
Evolving Past Three-Tier: The Natural Scaling Progression
Every production system outgrows the basic three-tier model in the same sequence. First the database becomes slow: add a caching layer (Redis/Memcached) for hot reads. Then the database cannot handle the write volume: add read replicas, split reads and writes. Then the single application server cannot handle traffic: add horizontal scaling behind a load balancer. Then different parts of the application have different scaling needs: extract high-traffic or CPU-intensive components as separate services. This is not microservices dogma. It is pragmatic evolution driven by actual bottlenecks.
Step 1: Vertical scaling - bigger database server. Fast to implement, limited ceiling, expensive.
Step 2: Read replicas - route read queries to replicas, writes go to primary. Adds complexity around replication lag.
Step 3: Caching layer - Redis or Memcached in front of the database. Cache-aside, write-through, or write-behind patterns.
Step 4: CDN for static assets - remove static file serving entirely from your application tier.
Step 5: Application tier horizontal scaling - multiple app servers behind a load balancer. Requires stateless applications.
Step 6: Database sharding or switching to a distributed database for write-heavy workloads.
What Interviewers Test About Three-Tier and HTTP
System design interviews almost always start with a three-tier setup and then probe how you evolve it. The interviewer wants to see that you know the failure modes of each tier and the specific tools/patterns that address each failure. Vague answers ('add more servers') are less valuable than specific answers ('add read replicas and route read traffic with a load balancer, accepting up to 100ms replication lag for non-critical reads'). HTTP knowledge shows up in API design questions, caching questions, and CDN questions.
Know: the difference between stateless and stateful application servers, and why stateless enables horizontal scaling
Know: HTTP caching headers (Cache-Control, ETag, Last-Modified) and how they interact with CDNs
Know: connection pooling between the app tier and database tier, and why max_connections is a database bottleneck
Know: when to use a reverse proxy (nginx/HAProxy) versus a cloud load balancer (ALB/ELB)
Know: the N+1 query problem and how ORMs cause it, with solutions (eager loading, DataLoader pattern)
Related reading
HTTP's Evolution: Why the Protocol Kept Changing
HTTP/1.0 (1996) opened a new TCP connection for every request. A page with 5 images required 6 TCP handshakes and 6 TLS negotiations. At slow modem speeds this was tolerable. At broadband speeds with 200 assets per modern page, it was catastrophic. HTTP/1.1 fixed this with persistent connections (keep-alive) and pipelining, but pipelining had a head-of-line blocking problem: a slow response blocked all queued requests behind it. HTTP/2 (2015) solved this with binary framing and full request multiplexing over a single TCP connection, plus header compression (HPACK). HTTP/3 (2022) replaced TCP itself with QUIC, eliminating TCP's inherent head-of-line blocking at the transport layer.
- HTTP/1.0: one TCP connection per request. Simple, but slow for asset-heavy pages.
- HTTP/1.1: persistent connections, pipelining, chunked transfer encoding, Host header enabling virtual hosting.
- HTTP/2: binary framing, stream multiplexing (multiple requests in parallel on one connection), server push, HPACK compression.
- HTTP/3: QUIC transport (UDP-based with reliability), eliminates TCP head-of-line blocking, faster connection establishment with 0-RTT.
- TLS 1.3 (2018): reduced handshake to 1-RTT from 2-RTT, 0-RTT session resumption. Security improvement with performance gains.
Evolving Past Three-Tier: The Natural Scaling Progression
Every production system outgrows the basic three-tier model in the same sequence. First the database becomes slow: add a caching layer (Redis/Memcached) for hot reads. Then the database cannot handle the write volume: add read replicas, split reads and writes. Then the single application server cannot handle traffic: add horizontal scaling behind a load balancer. Then different parts of the application have different scaling needs: extract high-traffic or CPU-intensive components as separate services. This is not microservices dogma. It is pragmatic evolution driven by actual bottlenecks.
- Step 1: Vertical scaling - bigger database server. Fast to implement, limited ceiling, expensive.
- Step 2: Read replicas - route read queries to replicas, writes go to primary. Adds complexity around replication lag.
- Step 3: Caching layer - Redis or Memcached in front of the database. Cache-aside, write-through, or write-behind patterns.
- Step 4: CDN for static assets - remove static file serving entirely from your application tier.
- Step 5: Application tier horizontal scaling - multiple app servers behind a load balancer. Requires stateless applications.
- Step 6: Database sharding or switching to a distributed database for write-heavy workloads.
What Interviewers Test About Three-Tier and HTTP
System design interviews almost always start with a three-tier setup and then probe how you evolve it. The interviewer wants to see that you know the failure modes of each tier and the specific tools/patterns that address each failure. Vague answers ('add more servers') are less valuable than specific answers ('add read replicas and route read traffic with a load balancer, accepting up to 100ms replication lag for non-critical reads'). HTTP knowledge shows up in API design questions, caching questions, and CDN questions.
- Know: the difference between stateless and stateful application servers, and why stateless enables horizontal scaling
- Know: HTTP caching headers (Cache-Control, ETag, Last-Modified) and how they interact with CDNs
- Know: connection pooling between the app tier and database tier, and why max_connections is a database bottleneck
- Know: when to use a reverse proxy (nginx/HAProxy) versus a cloud load balancer (ALB/ELB)
- Know: the N+1 query problem and how ORMs cause it, with solutions (eager loading, DataLoader pattern)
