Web Request Lifecycle Sequence Diagram: CDN to Database

Mermaid code

sequenceDiagram
    participant B as Browser
    participant C as CDN
    participant L as Load balancer
    participant A as App server
    participant R as Cache
    participant D as Database
    B->>C: GET /products/42
    alt Static asset cached at edge
        C-->>B: 200 from edge cache
    else Dynamic request
        C->>L: Forward request
        L->>A: Route to healthy instance
        A->>R: GET product:42
        alt Cache hit
            R-->>A: Product JSON
        else Cache miss
            A->>D: SELECT product 42
            D-->>A: Row
            A->>R: SET product:42 with 300s TTL
        end
        A-->>L: 200 HTML
        L-->>C: Response
        C-->>B: 200 HTML
    end

Paste this into any tool that renders Mermaid, or into the editor to change the theme and export PNG or SVG. Syntax reference: Sequence Diagram guide.

What this diagram shows

Six participants run across the top: Browser, CDN, Load balancer, App server, Cache, and Database. The outer alt separates the two fates of a request at the edge: served from the CDN cache, or forwarded to origin. Inside the origin path, a nested alt shows the cache hit and the cache miss, including the SET that fills the cache after a database read. Dashed arrows (-->>) are responses, solid arrows (->>) are requests.

A sequence diagram is the right type here because order and nesting matter. The same system drawn as a flowchart would show the components but hide which calls happen inside which branch.

How to adapt it

• Rename /products/42 and product:42 to one concrete request from your own app; a real URL makes the diagram easier to discuss than a placeholder.
• Add activate A and deactivate A around the app server work to show how long an instance is busy.
• Insert a Note over A,D: p95 = 40 ms line to attach measured latency to a hop.
• Drop the CDN participant if your app has no edge cache; the diagram still reads correctly with five lanes.

FAQ