Request routing, load balancers, and basic caching

Big picture: how a request flows

You want a mental picture of what happens from a user’s browser to your backend and back again.

A simple request path

Let’s imagine a user opening https://app.example.com/dashboard.

Typical path:

Walkthrough:

1. Client (browser / mobile app)

   • Makes an HTTPS request to app.example.com.
   • DNS for app.example.com often points to the CDN or load balancer.

2. CDN (Content Delivery Network)

   • Sits close to the user, globally distributed.
   • If the requested asset (e.g. /static/app.js, images, sometimes even HTML) is cached and fresh, it responds directly.
   • If not cached or not cacheable (e.g. personalized /dashboard), it forwards to your origin, often a load balancer.

3. Load balancer (LB)

   • Has a public IP / hostname (or is the “origin” from CDN’s point of view).
   • Receives requests and routes them across multiple app servers.
   • If one app server is down or being replaced, the LB stops sending traffic there. Clients don’t see this churn; they just keep calling the same LB address.

4. App server (application layer)

   • Runs your code (e.g. Node.js, Java, Python, Go).
   • Validates the user, runs business logic.
   • Reads data from and writes data to the database, often with intermediate caches (we’ll get to that).

5. Database (DB)

   • Stores persistent data.
   • Handles queries from app servers and returns results.
   • Often also fronted by its own caching or replicas.

Example you can picture:

• User visits /dashboard.
• CDN serves static /static/app.js from cache.
• The HTML for /dashboard is not cached at the CDN (personalized), so CDN forwards that request to the load balancer.
• Load balancer sends it to app-server-3.
• app-server-3 hits the DB for the user’s data, renders HTML, sends it back out through LB → CDN → client.