Two Cache Layers: What I Believed
The two-layer cache picture I drew from config files, and where it was wrong. A bypass header made the LB cache step aside on one route, but not the other.
A request passes two cache layers. I thought one bypass header always made the LB cache step aside.
This is the picture I drew after I read the config files. I kept it on purpose, because it is wrong.
What I Understood Then
- Akamai adds
X-Cache-Bypass: yesto every request sent to the origin. - The LB cache sees this header and skips its own cache.
- So when Akamai has a miss, it always gets the latest file from the bucket.
Where I Was Wrong
| What I thought | In reality |
|---|---|
The LB cache steps aside when it sees X-Cache-Bypass | Only the LB cache on the bucket backend has a rule that reads it. The one on the proxy backend does not (A Bypass Header Works Only Where a Rule Reads It) |
| An Akamai miss always gets the latest file | The proxy route gets the old copy from the LB cache (Stale-While-Revalidate: Serve Old First, Refresh in the Background) |
| Akamai decides the TTL | The LB cache first pushes the TTL down to 3600 seconds or less (TTL Is Set in Three Places) |
| One purge of Akamai is enough | A purge cannot reach the LB cache, and Akamai gets the old file back from it (Akamai Tools: Purge and CLI) |
This picture came from reading config files. It was not a test result. It holds only for the bucket route.
Reading config files gives you “should”. Sending one request gives you “actual”.
Related: Akamai Property: One Edge Config, Akamai Tools: Purge and CLI, How the Load Balancer Picks a Backend, TTL Is Set in Three Places, A Bypass Header Works Only Where a Rule Reads It. Or go back to the series overview.