Sketch a scalable web app front-door

1. End-to-end request flow: browser → database → browser

You’re going to draw a “front-door” diagram that shows what really happens when someone hits your web app, step by step.

A simple reference diagram

Here’s a minimal but scalable front-door as a starting point:

You’ll redraw this yourself, but with more labels: each arrow should have a small step number or annotation when you make your own version.

Step-by-step flow (what actually happens)

Imagine a user opens https://app.example.com/dashboard. Walk through it like a story:

1. Browser → DNS

   • What: Browser asks “What IP is app.example.com?”
   • Why: Names are for humans, IPs are for machines.
   • Effect: DNS returns an IP that points to your CDN or load balancer (often CDN first).

2. Browser → CDN

   • What: Browser sends an HTTPS request to that IP.
   • Why: CDN can serve static assets (HTML, CSS, JS, images) and sometimes cache API responses.
   • Effect:
     • If cache hit, CDN responds directly.
     • If cache miss, CDN forwards request to your load balancer.

3. CDN → Load balancer

   • What: Forward the request to your infrastructure entry IP(s).
   • Why: Load balancer chooses which instance actually handles the request.
   • Effect: One of your app-facing entry points is chosen.

4. Load balancer → API gateway

   • What: LB just does network-level distribution: passes HTTP request to one API gateway instance.
   • Why: API gateway centralizes cross-cutting concerns (auth, routing, rate limiting).
   • Effect: Gateway now owns understanding what the request is trying to do.

5. API gateway → App server

   • What: Gateway inspects path/headers (e.g. GET /api/dashboard) and forwards to the right app service or cluster.
   • Why: It can do token validation, logging, routing to dashboard-service versus user-service, etc.
   • Effect: The chosen app server process receives an internal HTTP/gRPC call.

6. App server → Database (and back)

   • What: App decodes the request, runs business logic, queries DB.
   • Why: This is where your domain logic lives.
   • Effect:
     • App runs queries against DB.
     • DB returns rows/documents.
     • App transforms them into JSON/HTML and sends a response back up the chain.

7. Back up the chain: App → Gateway → Load balancer → CDN → Browser

   • What:
     • App server → API gateway: sends response.
     • API gateway → LB: passes back.
     • LB → CDN: response travels to edge.
     • CDN → Browser: final HTTP response to user.
   • Why: Same chain, just reversed.
   • Effect: CDN can cache the response (if allowed) for future users; browser renders the page.

How to sketch this yourself

When you draw:

• Draw boxes left-to-right:

  Browser → DNS → CDN → Load balancer → API gateway → App servers → DB

• Draw arrows for the main request path and label them with step numbers:

  • 1. DNS lookup
  • 2. HTTPS request
  • 3. CDN forward (miss)
  • …

• Draw return arrows going back along the same path, with notes like response, cached, JSON.