Anatomy of a Request: From Browser to Database

Here's the full map of a typical large web application:

                        ┌───────────────┐
  User's browser/app ──►│      DNS      │  "Where is api.shop.com?"
          │             └───────────────┘
          │
          ├──── static files (JS, CSS, images) ────►  ┌──────────┐
          │                                           │   CDN    │──► Object storage
          │                                           └──────────┘   (images, videos)
          ▼
   ┌───────────────┐
   │ Load balancer │  spreads traffic, removes dead servers
   └───────┬───────┘
           ▼
   ┌───────────────┐
   │  API gateway  │  auth, rate limits, routing
   └───────┬───────┘
           ▼
   ┌──────────────────────────────┐
   │  App servers (stateless)     │  business logic
   │  [app 1] [app 2] [app 3]     │
   └───┬───────────┬──────────┬───┘
       │           │          │
       ▼           ▼          ▼
   ┌───────┐  ┌──────────┐  ┌────────────┐     ┌────────────┐
   │ Cache │  │ Database │  │   Queue    │ ──► │  Workers   │  emails, resizing,
   │(Redis)│  │ + replicas│ │(Kafka/SQS) │     │            │  notifications
   └───────┘  └──────────┘  └────────────┘     └────────────┘
                                                     │
                                                     ▼
                                              ┌─────────────┐
                                              │ Search index│
                                              └─────────────┘

Now let's follow one request: "Show me my order history" on a shopping app.

Step 1: DNS. The app looks up api.shop.com. DNS in system design is more than a phone book, as we'll see below. It can send you to the nearest data centre (a building full of servers).

Step 2: CDN for static files. The page's JavaScript, CSS, logos and product images come from a CDN server near you. It might be in your own city, so these load in a few milliseconds and never touch the company's main servers.

Step 3: Load balancer. The API request (GET /orders) reaches a load balancer, which picks a healthy app server. If one server has crashed, the load balancer simply stops sending traffic to it. It does this with health checks: small test requests that show if a server is alive.

Step 4: API gateway. It checks your login token (a small secret that proves who you are), makes sure you're not sending too many requests, and routes /orders to the order service.

Step 5: App server. The code runs: "get orders for user 42, newest first, 20 per page".

Step 6: Cache check. "Do we already have user 42's recent orders in Redis?" If yes (a cache hit), we reply in about 1 ms. If not (a cache miss), we go to the database.

Step 7: Database. The query runs, ideally using an index (post 5). An index is a sorted lookup list that lets the database find rows without reading the whole table. Reads might go to a read replica (a copy of the database that only answers reads) so the main database isn't overloaded. The result is stored in the cache for next time.

Step 8: Response. JSON (a simple text format for data) goes back through the gateway and load balancer to your phone. Product thumbnails in the response are CDN URLs pointing at object storage.

Step 9: Async work (for writes). Async means "not at the same time": the work happens later, and the user does not wait for it. If you had placed an order instead, the app would save it, reply quickly with "Order placed!", and put a message on a queue. Workers then send the confirmation email, update the search index, notify the warehouse and so on, without making you wait.

Where the time goes: a latency budget

A latency budget is a plan for how many milliseconds (ms) each step may use. Suppose the target is "order history loads in under 300 ms". A rough budget:

TCP is the protocol that opens a reliable connection. TLS is the layer that encrypts it. Both need a few round trips to set up, so apps reuse the connection. The biggest items are usually network distance and database queries, not your code. That's why CDNs, regions close to users, connection reuse and caching matter so much.

Synchronous vs asynchronous paths

A key design question for every feature is what the user must wait for, and what can happen later:

• Must be synchronous (user waits):
  • checking a password,
  • saving the order,
  • charging the card (the user needs to know it worked).
• Can be asynchronous (done later by workers):
  • confirmation emails,
  • generating invoices,
  • updating recommendations,
  • resizing uploaded images,
  • analytics.

Moving work to the async path makes responses faster and keeps the main flow working even if, say, the email provider is down.

DNS as a system-design tool

In post 1, DNS turned names into IP addresses. In system design, DNS is also a traffic director. A region is a part of the world where a cloud provider has data centres, such as Mumbai or Frankfurt:

• Geo-based routing (GeoDNS): users in India get the IP of the Mumbai servers; users in Germany get Frankfurt.
• Latency-based routing: send each user to whichever region answers them fastest.
• Weighted routing: send 95% of traffic to the old version and 5% to a new version, for safe testing. This is called a canary release: you show a new version to a few users first, to catch problems early.
• Failover routing: if health checks show the main region is down, answer with the backup region's IP.

The limitation: caching. DNS answers are cached by browsers, operating systems and internet providers, sometimes for longer than the TTL you set. TTL (time to live) is the number of seconds an answer may be kept before it must be asked for again. So DNS failover isn't instant. Some users keep going to the dead region for minutes. That's why DNS is often combined with other techniques.

Anycast is another approach. The same IP address is announced from many locations worldwide, and internet routing naturally delivers each user to the nearest one. BGP (Border Gateway Protocol, from post 1) is the system that routers use to tell each other which IP addresses they can reach. Cloudflare and Google's public DNS (8.8.8.8) work this way. There's no DNS trickery; the network itself finds the closest site.

DNS is also a single point of failure (one part that, if it breaks, stops everything). If your DNS provider goes down, nobody can find you. Large companies often use two DNS providers.

Do you need all of these boxes?

No. A good rule is to add components when a real problem appears:

Every box adds cost, latency and things that can break. Simple is a feature (post 6).