What is Caching

Every day, billions of users interact with systems that feel instantaneous. Google returns search results in 200 milliseconds. Netflix starts streaming your movie within seconds. Your bank shows your balance immediately. Yet behind these experiences lies a profound engineering challenge: the data users need is often stored far away, in databases that can take hundreds of milliseconds—or even seconds—to query.

So how do these systems create the illusion of speed? The answer, in almost every case, is caching.

Caching is arguably the single most important technique in system design for achieving high performance at scale. It's so fundamental that you'll find caches at every layer of the computing stack—from CPU registers to browser storage, from in-memory data structures to globally distributed content delivery networks. Understanding caching deeply is essential for any engineer designing systems that must be fast, scalable, and cost-effective.

At its essence, caching is the practice of storing copies of data in a location that is faster to access than the original source. When you cache data, you're making a trade-off: you're using additional storage (memory, disk, or network-accessible storage) to reduce the time and resources required to retrieve frequently accessed information.

The fundamental insight behind caching is simple yet profound: accessing data is not equally expensive across all storage mediums. There exists a hierarchy of access speeds in computing, and caching exploits this hierarchy by keeping hot (frequently accessed) data in faster—but typically smaller and more expensive—storage layers.

Look at the orders of magnitude in this table. Reading from RAM is roughly 100 times faster than reading from an SSD, and 100 million times faster than fetching data from a server in another geographic region. This staggering difference in access times is why caching is so powerful—and why it appears at so many layers of the stack.

The universal caching pattern:

Every cache follows the same basic pattern:

1. Request arrives — A component needs data
2. Cache lookup — Check if the data exists in the cache
3. Cache hit — If found, return cached data immediately
4. Cache miss — If not found, fetch from the slower source
5. Cache population — Store the fetched data in cache for future requests
6. Return data — Provide the data to the requester

This pattern repeats at every layer: CPU caches use it for memory access, browsers use it for web resources, CDNs use it for content delivery, and application servers use it for database queries.

Caching is effective because of a fundamental property of how programs and users access data: locality of reference. This principle observes that data access patterns are not random—they exhibit predictable clustering behaviors that caches can exploit.

There are two primary forms of locality that make caching effective:

Real-world manifestations of locality:

Locality of reference appears everywhere in computing and user behavior:

• Web browsing: Users visit a small set of websites repeatedly. A user might visit thousands of unique URLs over a year, but most of their visits are to the same few dozen sites.

• Database queries: In typical applications, 80-90% of queries access the same 10-20% of data. A few popular products, a few active users, and a few hot topics dominate access patterns.

• File access: Programs repeatedly access the same libraries, configuration files, and recently opened documents. The working set at any moment is far smaller than total storage.

• API calls: Certain API endpoints are called far more frequently than others. Authentication endpoints, core data fetches, and commonly used features dominate traffic.

The 80/20 rule in caching:

Perhaps the most important pattern is that a small fraction of data receives a disproportionate share of access. This is often called the 80/20 rule or Pareto principle: roughly 80% of requests access only 20% of the data. In extreme cases (viral content, popular products), the ratio can be even more skewed—99% of traffic hitting 1% of data.

One of the most remarkable aspects of caching is its ubiquity. Caches appear at virtually every layer of the computing stack, each layer independently applying the same fundamental principle to optimize for its specific access patterns and constraints.

Understanding where caches exist helps you recognize optimization opportunities and debug performance issues. A request in a modern web application might hit a dozen different caches before reaching the canonical data source.

A request's journey through caches:

Consider what happens when a user requests a product page on an e-commerce site:

1. Browser DNS cache checks if it knows the IP for www.store.com
2. OS DNS cache is checked if the browser cache misses
3. ISP/Resolver DNS cache is queried if local caches miss
4. Browser HTTP cache checks for a cached copy of the page
5. CDN edge cache is checked if the browser cache misses
6. Load balancer routes to an application server
7. Application in-memory cache checks for the product data
8. Distributed cache (Redis) is queried if the local cache misses
9. Database buffer pool serves the query from cached pages if possible
10. Disk cache serves the data from OS file cache if in RAM
11. Physical disk is accessed only if all caches miss

In a well-optimized system, most requests never reach the database, let alone the disk. The caches absorb the vast majority of load.

While caches vary in implementation, they share common structural elements. Understanding these components helps you reason about cache behavior, select appropriate cache solutions, and configure them correctly.

Cache key design:

Cache key design is surprisingly nuanced and critical to cache effectiveness. A good cache key must:

• Uniquely identify the cached data — different data must have different keys
• Be deterministic — the same request must always generate the same key
• Be efficient to compute — key generation shouldn't be expensive
• Include all relevant parameters — version numbers, user context, feature flags
• Exclude irrelevant parameters — request timestamps, request IDs

Example cache key patterns:

# Product data keyed by ID
product:12345

# User profile with version for cache busting
user:67890:v3

# Query results keyed by normalized parameters
query:products:category=electronics:sort=price:page=1

# Per-user personalized data
recommendations:user:12345:context:homepage

Common cache key mistakes:

• Including timestamps → Every request misses
• Forgetting user context → Different users see each other's data
• Different parameter ordering → Same query, different keys, duplicate caching
• Missing version numbers → Stale data served after schema changes

Every cached item goes through a lifecycle from creation to eventual removal. Understanding this lifecycle is essential for reasoning about cache behavior and debugging cache-related issues.

The stages of a cache entry:

1. Population (Cache Write)

A cache entry is created when data is fetched from the source of truth after a cache miss. The entry is stored with:

• The cache key
• The cached value (serialized if necessary)
• TTL information (expiration time)
• Creation timestamp
• Optional metadata (size, tags, etc.)

2. Fresh State

During the TTL period, the entry is considered fresh and valid. Cache hits during this period return the cached data without accessing the backend. This is where caching delivers its performance benefit.

3. Stale State

After the TTL expires, the entry transitions to stale. Different caching strategies handle staleness differently:

• Strict expiration: Stale entries are treated as misses
• Stale-while-revalidate: Return stale data while refreshing in background
• Lazy expiration: Keep serving stale until explicitly invalidated

4. Eviction

Entries are removed from the cache due to:

• TTL expiration: Entry has aged out
• Capacity limits: Cache is full, eviction policy selects victims
• Explicit invalidation: Application explicitly removes entries
• Memory pressure: System needs to reclaim memory

Not all data is equally suitable for caching. Different types of content have different caching characteristics, freshness requirements, and invalidation needs. Understanding these distinctions helps you design effective caching strategies.

Beyond performance, caching has profound economic implications for system design. Cache effectively, and you can serve orders of magnitude more traffic with the same—or fewer—backend resources. Cache poorly, and you overspend on infrastructure that should never have been necessary.

The cost multiplication effect:

Consider a web application handling 10,000 requests per second. Without caching:

• Each request queries the database
• Database requires expensive, high-IOPS instances
• You need multiple read replicas to handle the load
• Costs scale linearly (or worse) with traffic

With effective caching (assume 95% cache hit rate):

• Only 500 requests per second reach the database
• Smaller, cheaper database instances suffice
• Fewer replicas needed
• Costs scale sub-linearly with traffic

Beyond direct cost savings:

Caching impacts economics in additional ways:

• Reduced latency improves conversion: Studies show that every 100ms of latency can reduce conversion by 1%. Faster pages = more revenue.

• Lower egress costs: Serving content from CDN edge caches reduces origin data transfer, which is often a significant cloud expense.

• Capacity headroom: By reducing baseline load, caching provides headroom to handle traffic spikes without emergency scaling.

• Simplified scaling: With caching absorbing read load, you can often scale your backend for write load only—a much smaller number.

The caching multiplier:

Think of caching as a force multiplier for your infrastructure. A 95% cache hit rate means your backend effectively handles 20x more traffic than it would without caching. A 99% hit rate means 100x. This is why investing in caching expertise—understanding cache invalidation, selecting TTLs, designing cache keys—pays enormous dividends.