Akamai’s caching isn’t just about storing files closer to users; it’s a sophisticated system designed to predict what content will be requested next and pre-emptively place it in edge servers worldwide.
Let’s look at how a simple request flows and where Akamai’s magic happens. Imagine a user in Tokyo requesting a JavaScript file from your origin server in California.
User (Tokyo) -> Akamai Edge Server (Tokyo) -> Akamai Cache (Tokyo) -> Origin Server (California)
If the Tokyo edge server has a fresh copy of the JavaScript file in its cache, it serves it directly to the user. This is the fastest path. If it’s not in the cache, or if the cached copy is stale, the Tokyo edge server acts as a proxy, requesting the file from your origin server. Once it receives the file, it serves it to the user and stores a copy in its cache for future requests, based on your caching rules.
The core of Akamai’s caching behavior is controlled by cache rules. These rules are defined in your Akamai Property Manager configuration and dictate how different types of content are handled.
Here’s a simplified example of a cache rule:
{
"name": "Static Assets Rule",
"criteria": {
"url_path": {
"operator": "STARTS_WITH",
"values": ["/static/", "/assets/"]
}
},
"behaviors": [
{
"name": "Cache Key",
"settings": {
"query_string_behavior": "IGNORE",
"cookie_behavior": "IGNORE",
"header_behavior": "IGNORE"
}
},
{
"name": "Set Cacheability",
"settings": {
"cacheability": "CACHABLE",
"browser_cache_ttl": "3600s", // 1 hour
"edge_cache_ttl": "86400s" // 24 hours
}
}
]
}
This rule tells Akamai to cache anything with a URL path starting with /static/ or /assets/. Crucially, it specifies:
- Cache Key: How Akamai identifies unique versions of a file. Here, it ignores query strings, cookies, and headers, meaning
/static/app.js?v=1.0and/static/app.js?v=2.0would be treated as the same file, and/static/app.jswould also be the same. This is often a point of confusion. If you need query strings to differentiate versions, you’d changequery_string_behaviortoINCLUDE. - Set Cacheability: Whether the content can be cached and for how long.
browser_cache_ttlis how long the user’s browser will cache it, andedge_cache_ttlis how long Akamai’s edge servers will cache it.
Performance tuning involves understanding these rules and how they interact with your origin server’s Cache-Control headers. Akamai can be configured to respect, override, or merge these headers.
The most surprising thing about Akamai’s caching is that by default, it often prioritizes availability and performance over strict cache freshness for certain content types, especially if your origin server doesn’t send explicit cache-control directives. This means it might serve slightly stale content if it means a faster response time for the end-user, a behavior that can be tuned but is a fundamental design choice.
Let’s say you have an API endpoint, /api/user/profile, that returns dynamic data. If you don’t configure Akamai to not cache this, or to cache it for a very short duration, you might see stale data being served.
{
"name": "API Cache Rule",
"criteria": {
"url_path": {
"operator": "EQUALS",
"values": ["/api/user/profile"]
}
},
"behaviors": [
{
"name": "Set Cacheability",
"settings": {
"cacheability": "NOT_CACHABLE", // Or a very short TTL like "30s"
"browser_cache_ttl": "0s",
"edge_cache_ttl": "0s"
}
}
]
}
Setting cacheability to NOT_CACHABLE ensures every request goes back to your origin. Alternatively, setting a short edge_cache_ttl, like 30s, allows Akamai to cache it for a brief period, reducing origin load while still providing near real-time data. The browser_cache_ttl is also set to 0s to prevent the browser from holding onto the data.
A lesser-known but powerful aspect of Akamai’s caching is the ability to use "Forward to Origin" settings within the "Set Cacheability" behavior. When you configure a cache rule, you can specify how Akamai forwards requests to your origin. For example, you can choose to forward specific headers (like Authorization or custom headers) or query strings to the origin to ensure the cache key is unique only when those elements change. If you’re using Akamai’s EdgeWorkers or Serverless Computing Platform, you can dynamically generate cache keys based on complex logic, offering granular control over what constitutes a unique cacheable object.
The next hurdle you’ll likely encounter is understanding how Akamai’s Purge API works and how to effectively invalidate cached content when it changes on your origin.