Cache-Aside Pattern

Databases are great at safely storing structured data, but as your application scales, asking the database to perform complex queries over and over again becomes a massive bottleneck. Databases are generally stored on disk (SSD/HDD), which is relatively slow.

To speed things up, we introduce a Cache, usually an in-memory data store like Redis or Memcached. Memory (RAM) is incredibly fast.

But how exactly should your application interact with the database and the cache? Do you write to both? Who reads from where? The most common architectural pattern to solve this is the Cache-Aside Pattern (also called Lazy Loading).

What is the Cache-Aside Pattern?

In the Cache-Aside pattern, the cache sits aside the database. The database and the cache do not talk to each other directly.

Instead, your application code acts as the mediator. The application is completely responsible for checking the cache, pulling data from the database if there's a miss, and populating the cache for next time.

The Analogy: The Library and the Cheat Sheet

Imagine you are studying for an exam. The university library (the Database) has the massive, comprehensive textbook with all the answers, but walking there and finding the book takes 20 minutes.

You decide to keep a small notepad (the Cache) on your desk.

1. When you need an answer, you look at your notepad first.
2. If the answer is there (Cache Hit), great! You saved 20 minutes.
3. If the answer is not there (Cache Miss), you begrudgingly walk to the library, look up the answer in the textbook, and bring it back.
4. Crucially: Before you sit back down, you write the answer on your notepad so you don't have to walk to the library for that specific question ever again.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

On a cache miss the app fetches from the database, then writes the result back into Redis so the next request is a fast cache hit.

1 / 10.5×1×2×3×Playground

Cache miss read path: the app checks Redis, misses, queries the database, then populates the cache for future requests.

How it works step-by-step

Let's look at how an application retrieves a user profile in a Cache-Aside system.

Reading Data:

1. The application receives a request: GET /users/123.
2. The application checks the cache (e.g., Redis): GET user:123.
3. If the data exists (Cache Hit), the app returns it immediately.
4. If it doesn't exist (Cache Miss), the app queries the database: SELECT * FROM users WHERE id = 123.
5. The app takes the database result, writes it to the cache (SET user:123 {...}), and returns the response.

Writing Data: When data is updated, the cache becomes stale. In a Cache-Aside pattern, the application usually writes the new data directly to the database, and then deletes (invalidates) the cached copy.

1. The application receives an update: PUT /users/123.
2. The app updates the database: UPDATE users SET name = 'Bob' WHERE id = 123.
3. The app explicitly deletes the cache entry: DEL user:123.
4. The next time a read happens, it will be a Cache Miss, fetching the fresh data from the DB.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

On a write, the app updates the database first, then deletes the cache entry. The next read will be a miss that fetches fresh data and repopulates the cache.

1 / 10.5×1×2×3×Playground

Write path: the app updates the database first, then deletes the stale cache entry so the next read gets fresh data.

Real-World Examples

• Reddit Comments: When you load a popular Reddit thread, Reddit doesn't query the massive Postgres database for thousands of comments. The application asks Redis for the cached comment tree. If the cache expired, it hits the database, builds the tree, and stashes it back in Redis.
• E-commerce Product Catalogs: An item's title and description rarely change. An API will use cache-aside to serve product details from memory, ensuring fast page loads for customers.

Pros of Cache-Aside

1. Resiliency: If the cache (Redis) completely crashes, the system doesn't go down. The application code simply experiences a cache miss and falls back to reading directly from the database. Though your database might struggle with the sudden spike in load.
2. Efficiency: Data is only cached if it is actually requested (lazy loading). You aren't wasting expensive RAM storing data that no one is looking at.
3. Data Model Flexibility: The cache doesn't have to perfectly mirror the database row. Your application can run a complex SQL JOIN across 5 tables, and save the aggregated JSON result into the cache.

Cons and Trade-offs

1. The Initial Penalty: The very first time a user requests data, they suffer a penalty. They have to wait for the cache check, the database query, and the cache write.
2. Stale Data Risks: Because the database and cache are disconnected, if a developer writes a script that updates the database manually and forgets to wipe the cache, users will see old, stale data until the cache naturally expires (TTL).

Summary

The Cache-Aside pattern places the application in control of both the database and the cache. By explicitly checking the cache first, falling back to the database on a miss, and then populating the cache with the result, systems achieve massive performance boosts. It's the most widely used caching strategy due to its simplicity, resilience, and efficiency in ensuring only actively requested data takes up valuable memory space.