Part 9 — Layer 7: Application

In our story

Three L7 protocols take part in your one click: DNS, HTTP, and the Postgres protocol.

Step A: DNS (assuming nothing is cached). The browser needs an IP for shop.example.com:

Browser cache?        miss
OS resolver cache?    miss
 │
 ▼ UDP 53 → home router 192.168.1.1 (DNS forwarder) → ISP recursive resolver
                                                         │
     ┌───────────────────────────────────────────────────┘
     │ 1. Root server       "who handles .com?"           → a.gtld-servers.net ...
     │ 2. .com TLD server   "who handles example.com?"    → ns1.example-dns.net ...
     │ 3. Authoritative     "shop.example.com?"
     │       → CNAME shop-alb-123.region.elb.example.net
     │       → A     198.51.100.20   TTL 60
     ▼
Browser now has 198.51.100.20 (cached for 60 s)

DNS is an L7 protocol carried over UDP (L4), falling back to TCP for large responses. Increasingly it's encrypted (DNS-over-HTTPS/TLS). A cold lookup can take 20–100 ms or more. A cached one takes 0 ms.

Step B: the HTTP request. Inside the TLS tunnel, on HTTP/2 stream 15:

:method: POST
:scheme: https
:authority: shop.example.com
:path: /api/v1/orders
content-type: application/json
content-length: 43
cookie: session=s%3A9d8f...; AWSALB=...
idempotency-key: 7f3c9a2e-1b4d-4c8e-9f00-2a6b8d1e5c43
user-agent: Mozilla/5.0 ...
accept-encoding: gzip, br

{"cartId":"c_8812","paymentMethodId":"pm_77"}

Step C: L7 routing at the load balancer. Because the ALB decrypts the traffic and parses HTTP, it can make content-aware decisions that an L4 device can't:

Rule: Host = shop.example.com AND Path = /api/v1/orders*  → target group "orders-service"
Adds: X-Forwarded-For: 203.0.113.7      (your public IP, which is otherwise lost)
      X-Forwarded-Proto: https
      X-Amzn-Trace-Id: Root=1-6703...   (distributed-tracing correlation ID)
Picks a healthy pod: 10.0.2.77:8080 (least outstanding requests)
Sends over an existing keep-alive connection, HTTP/1.1 (or HTTP/2, gRPC)

Step D: your code. The orders-service handler:

1. Authenticate: look up the session cookie (Redis) → user u_4411
2. Idempotency: have we seen key 7f3c9a2e...? No → record it
3. Business logic: price the cart, call the payment provider (another full
   outbound L1–L7 journey through the NAT gateway!)
4. Persist: INSERT INTO orders ... over a pooled Postgres connection
   (Postgres wire protocol, L7, over TCP 5432, often TLS)
5. Respond: 201 Created  {"orderId":"o_99120371","status":"confirmed"}

Every outbound call in step D repeats the entire OSI journey on a different path. A single user click usually fans out into 5–50 internal L7 conversations.