Lesson 7 · Cache at the edge

Sometimes, skip the origin entirely.

A local CDN sits in front of the complete Lesson 6 origin. Product reads are cached for 15 seconds; a cache hit returns straight from the CDN and never reaches the Edge Load Balancer, an API Gateway, or a service.

Content Delivery Network Edge caching Cache TTL HIT / MISS / BYPASS

Interactive caching lab

Watch a MISS populate the cache, then a HIT skip everything downstream.

Request Products twice inside 15 seconds. The first response is stored at the CDN; the second returns from that cache alone.

Demo cache policy: only GET /api/products is cached, for 15 seconds. User and Order routes always bypass the cache. This rule lives in the CDN configuration and is intentionally changeable.

Choose an APIOnly Products is cached

Only known address http://127.0.0.1:7712/api/products

You can run the selected request in Postman.

Start the lesson, then request Products twice.

Execute a request to inspect the original response.

Execute a request to inspect the response headers, including X-Cache-Status.

Only known address

CACHE

Infrastructure statusSTOPPED

Cache resultWAITING

Current journeyCDN → waiting

Stateless gateway tierTwo identical L7 routers

Internal routingService destinations

Direct · always BYPASS/api/users

Cached for 15s/api/products

Direct · always BYPASS/api/orders

Observe the cache

Did this request reach the origin?

A HIT answers from the CDN alone. A MISS or BYPASS travels the complete Lesson 6 path before the CDN can respond.

Latest cache outcome WAITING Execute a request to reveal every component it touched.

Requested routeWaiting

Cache resultWaiting

Final serverWaiting

1
Start the lessonThe trace will separate a cache answer from a full origin round trip.

Why request twice?

The first Product request after a start or a cleared cache is always a MISS: nothing is stored yet, so the CDN forwards it to the origin and keeps a copy. A second request inside the 15-second TTL is a HIT and never leaves the CDN.

Local CDN logevery request → cache result

Start Lesson 7.

Edge/L4 logMISS / BYPASS only

Origin is skipped on HIT.

API Gateway 1 logpath → service

Origin is skipped on HIT.

API Gateway 2 logpath → service

Origin is skipped on HIT.

Catalog L7 logProducts only, MISS only

Origin is skipped on HIT.

What this teaches

Cache responses closer to the client.

This is a good point to introduce a CDN (Content Delivery Network) and response caching. A CDN sits closer to the client than any part of the origin and can answer frequently requested, cacheable content directly.

Client→CDN→Edge Load Balancer→API Gateway→Services

If the requested content is already cached, it returns directly and the request never reaches the origin:

Client→CDN cache→Response

On a cache miss, the CDN forwards the request through the full origin chain and may store the response so future requests can be served directly.

Reduced origin traffic

A HIT never reaches the Edge Load Balancer, a Gateway, or a service.

Reduced backend load

The Catalog tier answers fewer requests during traffic spikes.

Faster responses

One cache lookup replaces several internal routing decisions.

Serves from the edge

In production, requests are answered from a location closer to the client.

CACHE

Local CDN

Answers cacheable reads directly and forwards everything else to its configured origin.

ORIGIN

Lesson 6 infrastructure

The full Edge Load Balancer, API Gateway, and Catalog Load Balancer chain, reached only on a MISS or BYPASS.

Note: real systems usually have several load balancers

A CDN does not discover its destination automatically. Its distribution is configured with an origin hostname or an origin group.

Cache behaviors can map request paths to the desired origin. DNS, Anycast, or a global traffic manager can then resolve that origin hostname to the appropriate regional or edge load balancer. From there, internal load balancers continue routing traffic to the correct gateway and service instances.

Origin groups can also define a primary and secondary origin so the CDN can fail over when the primary origin is unavailable.

Anycast gets a proper explanation in Lesson 8 — though note it is used in the opposite direction there. This note is about how the CDN finds its origin; Lesson 8 is about how a client finds the CDN.

What this gives us

Cache hits skip the entire origin chain
Lower backend load during traffic spikes
Faster responses for cached content
An explicit, per-route cache policy
The origin remains authoritative on a MISS

What still remains

This single CDN container is now a SPOF of its own — if it stops, everything stops, cached or not. Lesson 8 (bonus) shows why that worry mostly dissolves in the real world, where a CDN is one address served from many locations at once.
Cached content can be stale for up to the TTL window
Every non-cached route still crosses the full origin chain
Cache policy must be chosen deliberately per endpoint

One question this lesson leaves open

We just put a single box in front of everything. Isn't that a step backwards?

Seven lessons spent removing single points of failure, and then this one puts a single container in front of the whole system. The bonus lesson explains why that isn't the problem it looks like — a real CDN is one address answered by many locations at once, so losing any one of them is a routing update rather than an outage.

Bonus: Why a real CDN isn't one box →