Access Time

Access time is how long a storage device takes to locate and return a piece of data. On a rotating drive, access time is the delay before transfer begins: "The access time or response time of a rotating drive is a measure of the time it takes before the drive can actually transfer data". Moving the bytes afterwards is counted separately. That is because access time and data transfer rate are the two distinct categories of drive performance (Wikipedia: HDD access time). Access time is also not network latency. It is not TTFB either. On a cache hit, though, it becomes one component of both.

The span is the point. A random read costs roughly 13 ms on a 7,200 RPM hard disk. On an SSD it costs tens to a couple of hundred microseconds. In main memory it costs about 100 ns. That is five orders of magnitude from top to bottom of the ladder. That gap is why every performance-sensitive system keeps a hierarchy of caches, including a CDN. On a cache hit, the access time of whichever tier holds the object is the floor under how fast an edge server can start sending bytes.

How it works

Access time on a rotating drive is composed of a few independently measurable elements. These add together into a single value. Access time varies enough that it "is typically provided by manufacturers or measured in benchmarks as an average" (Wikipedia). Four components make it up: seek time, rotational latency, command processing time and settle time. The first two dominate. Command processing is on the order of 3 microseconds. Settle time is typically under 100 microseconds. It is normally already folded into the manufacturer's seek-time specification (Wikipedia: command and settle overhead).

• Seek time: "the seek time measures the time it takes the head assembly on the actuator arm to travel to the track of the disk where the data will be read or written". The most common desktop drives are typically around 9 ms. The fastest high-end server drives of 2010 were around 4 ms. Seek time "has continued to improve slowly over time" since then. So treat 4 ms as a floor for mechanical drives, not a current typical value. A track-to-track seek is the shortest kind. It is typically 0.2 to 0.8 ms (Wikipedia: seek times).
• Rotational latency is the wait for the platter to bring the wanted sector under the head. Maximum latency is one full revolution, 60/RPM. The average is half of that. The published figures are 4.17 ms average at 7,200 RPM, 3.00 ms at 10,000 RPM and 2.00 ms at 15,000 RPM (Wikipedia: rotational latency). Unlike seek time, this is fixed by spindle speed. It cannot be engineered away without spinning faster.

Add the two and a 7,200 RPM desktop drive lands near 13 ms for a random read (about 9 ms seek plus 4.17 ms average rotational latency). A 15,000 RPM enterprise drive with a 4 ms seek lands near 6 ms. On the order of ten milliseconds is the honest figure for a spinning disk. Any single precise number reflects a specific drive, not a rule.

An SSD has no moving parts. So measuring its seek "is only testing electronic circuits preparing a particular location on the memory in the storage device". The same page adds: "Typical SSDs will have a seek time between 0.08 and 0.16 ms" (Wikipedia: comparison to SSDs). Flash-era numbers move quickly. The widely cited interactive latency-numbers table currently puts an SSD random read at about 16 microseconds. It puts a main-memory reference at 100 ns (Latency Numbers Every Programmer Should Know). Memory is also location-independent. A random-access memory device "allows data items to be read or written in almost the same amount of time irrespective of the physical location of data inside the memory" (Wikipedia: RAM). This is because there is no arm to move and no platter to wait for.

Why it matters for a CDN

On a cache hit, the edge answers out of its own storage. The access time of that tier sets the floor under TTFB. This is measured, not theoretical. Cloudflare reports that "cache hit tail latency within our system is dominated by the IO capacity of our SSDs" (Cloudflare engineering blog). At CDN scale, the edge's own drives shape the slow tail of otherwise successful hits. Specifically, it is their IOPS budget that matters. The customer's origin does not shape that tail.

A cache miss inverts the picture. The edge must fetch from the origin across the network. A round trip costs roughly 500 microseconds even inside a single datacenter. It costs about 150 ms from California to the Netherlands (latency numbers). That dwarfs any local storage access time. On a miss, the network dominates. The edge disk is effectively irrelevant.

Between those two facts sits the operator's main lever. Cache hit ratio decides how often a request is answered in microseconds from memory or flash. It also decides how often a request falls all the way to a network round trip. Storage tiering decides the rest. The hottest objects sit in memory, warm content sits on SSD, and cold content sits on spinning disk, where such a tier exists at all.

What CDNs do

• Cloudflare: its cache storage layer "is powered by high IOPS NVMe SSDs". It also added a memory-SSD hybrid system. That system writes every cacheable asset into a memory "transient cache" first. It promotes the asset to the SSD-backed permanent cache only after the asset has been accessed enough times to prove popular. Cloudflare reported disk writes reduced by 25% at peak and 20% off peak. Cache hit tail latency measurably decreased. The rollout was conservative. It ran only on newer server generations with more physical memory. It covered only a subset of assets and a portion of traffic. No customer-facing control over it is documented (Cloudflare engineering blog).
• Fastly: it describes its edge cache as "an enormous pool of storage across the platform's network". It does not document the storage media behind it. It does state, as a platform-wide caveat: "All data stored in the Fastly cache is ephemeral: it will expire, and may be evicted by the platform before it expires depending on how frequently it is used." It directs customers who need persistent edge state to dictionaries, access control lists or data stores instead (Fastly docs).

Watch out for

• Access time is not one number. It "can vary significantly". That is why it is published as an average (Wikipedia). An average hides exactly the tail that hurts a CDN. In distributed systems, "access time or latency should be measured at the 99th percentile" (Wikipedia: access time). So report p99 rather than the mean.
• On flash, writes are what cost you. "Worn out SSDs are solely caused by writes, not reads". Writes also slow reads. An SSD write needs program/erase operations issued to the storage chips. Those operations block reads to the same chips. One-hit-wonders are assets written into cache and then never read again. Caching them spends both write endurance and cache-hit latency for nothing (Cloudflare).
• RAM is volatile. Stored information "is lost if power is removed" (Wikipedia: RAM). So a memory tier is a latency optimisation, never durable storage. Anything that must survive a restart belongs on flash or disk. Or it belongs outside the cache entirely, on a platform whose cache is explicitly ephemeral.
• Published latency tables model trends. They do not measure your hardware. The popular interactive latency-numbers page extrapolates disk seek from a year-2000 anchor of about 10 ms halving every decade. So it currently renders roughly 2 ms for a disk seek (latency numbers). That is below what any real 7,200 RPM drive can do, because its 4.17 ms average rotational latency alone is fixed by spindle speed. Use such tables for orders of magnitude only. Take drive figures from the drive's own specification.
• SMR drives have a write cliff. Shingled magnetic recording overlaps tracks for density. As a result, "sustained random writes are significantly slower on SMR drives" than on conventional ones (Wikipedia: SMR drives). That makes SMR a poor fit for any cache tier that is continuously rewritten as eviction churns its contents.

Best practice

• Keep the hottest objects in the memory tier. Keep warm objects on flash. Reserve any spinning-disk tier for genuinely cold content, if you run one at all.
• Raise cache hit ratio before tuning storage. A miss costs a network round trip. That round trip is orders of magnitude more than any local access time. So hit ratio outranks disk choice.
• Do not write to flash what you will not read again. Skip caching one-hit-wonders and throwaway responses. Fewer writes mean both longer SSD life and faster cache-hit reads.
• Measure the storage contribution at p99, not the mean. Separate it from network latency before optimising. If TTFB is dominated by an origin round trip, faster disks will not move it.
• Treat every cache tier as volatile. Memory is lost on power loss. Platform caches may evict content before it expires. So keep the authoritative copy at the origin, or in purpose-built persistent edge storage.