High-Performance Caching — Redis, CDNs, DNS & The Cache-Aside Pattern (2026)

BACKEND ARCHITECTURE MASTERY

Day 13: Memory Over Matter — Redis, CDNs & The Speed of Light

• ⏱️ 22 min read
• Series: Logic & Legacy
• Day 13 / 30
• Level: Senior Architecture

 We have perfected our database models and normalized our schemas. But relational databases store data on physical disk drives. No matter how well you index a PostgreSQL table, physical disk I/O will always be the bottleneck of the internet. To scale to millions of users, we must stop reading the disk.

The Speed of Light Limitation

If an API requests 50 user records from a database, the DB engine must parse the SQL, query the index, move the disk reader, load the blocks into memory, serialize the data, and send it back over the network. This takes milliseconds. In computing, a millisecond is an eternity.

Caching is the architectural practice of storing a copy of frequently accessed, expensive-to-compute data in an ultra-fast, temporary storage layer. Today, we architect the cache.

▶ Table of Contents (Click to Expand)

1. The Three Domains of Caching
2. Network Caching: CDNs and DNS
3. The Entire Flow of Caching (Cache-Aside)
4. Disk vs RAM: Postgres vs Redis Execution Results
5. The YouTube Architecture: Edge Caching via DNS
6. The Laws of Ephemerality: TTL
7. Eviction Policies
8. Architect's Disclaimer

1. The Three Domains of Caching

Caching is a fundamental law of physics applied at every layer of computation:

• Hardware-Based (L1/L2/L3 Cache): Silicon built directly into your CPU. Instead of waiting for data from the computer's main RAM, the CPU keeps a tiny amount of critical instructions physically microns away from the processing cores. It operates in nanoseconds.
• Software-Based (Redis/Memcached): An application layer cache. Data retrieved from a slow database (Disk) is stored as a Key-Value pair in the server's main memory (RAM). It operates in microseconds.
• Network-Based (CDN/DNS): The outermost shield. Data is stored on remote proxy servers geographically closer to the end user. It operates in milliseconds, preventing the request from ever reaching your primary servers.

2. Network Caching: CDNs and DNS

Why do we use network caching? Because fiber optic cables are fast, but they still obey the speed of light. If your server is in New York, a user in Tokyo will experience at least 150ms of latency just waiting for light to bounce across the ocean.

The CDN (Content Delivery Network)

A CDN (like Cloudflare or Akamai) is a global network of servers (Edge Nodes). When you upload a 5MB image to your New York server, the CDN creates copies of that image and stores them in Tokyo, London, and Sydney. When the Tokyo user requests the image, it is delivered from the Tokyo node in 10ms. Your New York server never even knew the request happened.

Similarly, DNS (Domain Name System) caches the translation of www.google.com to its IP address 142.250.190.46. Your computer, your router, and your ISP all cache this translation so they don't have to constantly hit the global root servers, which would instantly buckle under the weight of the entire internet.

3. The Entire Flow of Caching (The Cache-Aside Pattern)

Returning to the software layer: how do we implement RAM caching in Python? The most robust architecture is the Cache-Aside pattern. The application code is entirely responsible for managing both the cache and the database.

1. Step 1: The Application asks Redis (the Cache) for the data using a specific key (e.g., users:top_50).
2. Step 2 (Cache Hit): If found, Redis returns the data instantly. The API request finishes without ever touching the database.
3. Step 3 (Cache Miss): If not found in Redis, the Application queries PostgreSQL (the DB).
4. Step 4: The Application saves the Postgres data into Redis so the next request succeeds.
5. Step 5: The Application returns the data to the user.

4. Disk vs RAM: Postgres vs Redis Execution Results

Redis is an open-source, in-memory data store. Because it bypasses the physical SSD, it is terrifyingly fast. I have implemented a full asyncpg and redis-py engine in today's GitHub repository. Here is the exact implementation and the resulting execution benchmark when fetching 50 rows.

Python Cache-Aside Implementation

async def get_top_50_users(self):
    cache_key = "users:top_50"

    # 1. Attempt RAM Fetch (Cache)
    cached_data = await self.redis_client.get(cache_key)
        
    if cached_data:
        print("[✅ CACHE HIT] Data found in Redis.")
        return orjson.loads(cached_data) 
            
    else:
        print("[❌ CACHE MISS] Data not in Redis. Hitting PostgreSQL...")
        # 2. Fallback to Disk Fetch
        users = await self.fetch_users_from_db()
            
        # 3. Store in RAM for future requests with a 60-second TTL
        await self.redis_client.setex(cache_key, 60, orjson.dumps(users))
        return users

Live Execution Benchmark

--- FIRST REQUEST (Expecting Miss) ---
[❌ CACHE MISS] Data not in Redis. Hitting PostgreSQL...
--> Postgres Fetch Time: 15.420 ms
[SYSTEM] Data written to Redis with 60s TTL.

--- SECOND REQUEST (Expecting Hit) ---
[✅ CACHE HIT] Data found in Redis.
--> Redis Fetch Time: 0.315 ms

# CONCLUSION: Redis (RAM) is ~49x faster than PostgreSQL (Disk).

5. The YouTube Architecture: Edge Caching via DNS

How does YouTube flawlessly stream 4K video to millions of users simultaneously without its central database catching fire? It uses a profound combination of DNS and Network Edge Caching.

YouTube's central servers do not serve videos directly. Google installs massive physical hardware caches called Google Global Cache (GGC) nodes directly inside the datacenters of your local ISP (Internet Service Provider) like Comcast or Verizon.

How YouTube uses DNS to make decisions:

1. You click a video. Your browser asks the DNS: "Where is this video?"
2. Google's highly intelligent DNS servers look at your IP address and identify your specific ISP and geographic city.
3. Instead of returning the IP of a central California server, the DNS returns the IP address of the cache node sitting right down the street from your house.
4. Your video player connects to that local node. It continuously measures the network latency to that specific node. Based on how fast the local node replies, YouTube dynamically lowers or raises the video quality (1080p to 720p) to prevent buffering.

6. The Laws of Ephemerality: Time To Live (TTL)

RAM is extremely expensive. You cannot cache your entire database. Caching requires strict architectural rules to prevent memory exhaustion and stale data.

Data in the cache must have an expiration date. In the code above, setex("key", 60, data) tells Redis to enforce a TTL (Time To Live). Redis will automatically delete the data after exactly 60 seconds. This ensures that if the database is updated (e.g., a user changes their username), the cache will naturally purge the old record and reflect the new reality within one minute, minimizing the risk of Stale Data.

7. Eviction Policies

What happens if your server only has 2GB of RAM, you set a very long TTL, and you try to insert 3GB of cache? Redis will execute an Eviction Policy.

When Redis reaches its maxmemory limit, it must decide what to delete to make room for new data. The most common enterprise standard is LRU (Least Recently Used). Redis tracks which keys haven't been requested by the API in a while and silently deletes those neglected keys to make room for new, highly-requested data.

Alternatively, LFU (Least Frequently Used) deletes keys that have the lowest overall click count, regardless of when they were last touched.

🚧 Architect's Note: The Journey Continues

Caching is famously one of the two hardest problems in computer science. Today, we mastered the basics. Caching is not completed. In our upcoming advanced posts, we will dive into brutal Edge Cases: Cache Invalidation Strategies (Write-Through vs Write-Behind), mitigating the Thundering Herd (Cache Stampede), and distributed Redis Clusters. But first, we must understand the very fabric of the internet's routing layer.

Memory: Optimized

You have learned how to bypass physical disk latency and leverage RAM. Hit Follow to catch Day 14, where we execute a DNS DEEP DIVE and master how domains actually route traffic across the globe.

← Previous Day 12: Alembic Migrations Next → Day 14: DNS Deep Dive