The Akamai Intelligent Platform delivers 95 exabytes of data, ingests 2.5 exabytes of data, and interacts with 1.3 client devices per day. The platform reacts when content is in high demand by caching content (keeping a local copy of an object to send to the next user to request it). On a network with over 140,000 servers deployed in more than 2200 locations around the world, we think it's important to ensure that these sorts of events are transparent to our customers.

Caching is done using a pull model. Akamai does not know about objects for which we haven’t seen requests, nor do we push content out to our servers in order to pre-warm our caches. One slight exception to this is the Prefetching feature. Prefetching is where the servers examine the web page that is being downloaded or the video stream being requested and proactively make requests ahead of the user to ensure that there is an object in cache before the user gets around to requesting it. This is still part of the pull model as we need to get a request for an object in order to learn about related objects that we should download and the action is taken independently by each of our server deployments.

After downloading an object the Akamai servers will save a copy of it. Servers within the same deployment are able to check each other’s caches using the Inter-Cache Protocol (ICP). This means that the amount of storage space for caching content is the sum of the storage space of all the servers in that deployment.

When our DNS servers reply to lookup requests, we generally return two IP addresses for any given deployment. Both servers will cache the objects that they serve, so the total cache space is half the total storage space of that deployment. This redundancy allows us to take machines out of service for installs, or maintenance, or due to an outage, and still be able to serve their objects without having to send requests to the origin. As the cache on a server fills up, our software looks for the least recently used objects in its cache and evicts them to make room for new objects. Objects that are requested most often will remain in cache for a long time, while less requested objects will be automatically purged as requests for new objects arrive. Content is never evicted unless there are requests for new objects and there is no existing room in the cache for them, or unless the customer explicitly issues a purge request to have an object removed from the network.

For websites with a particularly high volume, or during request surges, Akamai offers a Tiered Distribution method (AKA cache hierarchy). Tiered Distribution creates "layers" of cached objects, depending on access to speed and frequency of object request. The first layer of a cache hierarchy is the highest speed and is made up of the most requested objects. When that is filled, a second layer, which is slightly slower will be created with the second most requested items, and so on. This allows for reduced latency and highly efficient delivery from caching.