Cache aside

API Design

Meaning

Cache aside is a caching strategy where the application layer is responsible for reading from and populating the cache, while the underlying data store remains the source of truth. It addresses the pain point of reducing read latency and database load without coupling the data store to the cache or requiring the store to support cache invalidation natively. Developers reach for it when they need fast reads on hot data but cannot or do not want to modify the primary store to manage cache coherence itself.

Primary Function

Caching strategy

Communicative Purpose

Ensures the application layer controls cache reads and writes, keeping the data store decoupled from the cache while maintaining consistency on demand.

Pattern

read request → check cache → on miss, read from store → populate cache → return; write request → update store → invalidate cache entry

Função primária

Caching strategy

Propósito comunicativo

Ensures the application layer controls cache reads and writes, keeping the data store decoupled from the cache while maintaining consistency on demand.

Situações de gatilho

Web applications: serving frequently-read entities like user profiles or product catalogs

Contextos

Web backends, microservices, distributed systems, read-heavy APIs, ORM-backed applications

Padrão

read request → check cache → on miss, read from store → populate cache → return; write request → update store → invalidate cache entry

Colocados típicos

read-through cache
write-through cache
cache invalidation
TTL
cache stampede
lazy loading

Substituições comuns

Read-through cache (cache populates itself on miss
hiding the store from the caller)
Write-through cache (writes propagate to cache and store synchronously
eliminating the invalidation step)
Write-behind cache (writes buffered and flushed asynchronously
lower write latency but risk of data loss on crash)

Erros comuns

Forgetting to invalidate cache after writes: stale data served indefinitely until TTL expires

Similar / contraste

Read-through cache: cache itself fetches from store on miss, caller unaware of the miss

Interferências

Coming from hardware caching mental model: may assume the cache is always coherent — cache-aside requires explicit invalidation by the application

Família do chunk

read-through cache
write-through cache
write-behind cache
cache invalidation
cache stampede

Nuance

When NOT to use: write-heavy workloads where invalidation cost exceeds read benefit, or when the data store already provides built-in query caching

Efeito pragmático

Reduces database load and read latency for hot data while keeping the data store as the single source of truth, at the cost of explicit invalidation logic in the application.

Dica de memória

Cache aside: like a librarian who checks the front desk for a book first, and only walks to the archives when it's not there — and tears up the desk card whenever the archives get a new edition.

Upgrade path

Read-through cache with stampede protection, or write-behind caching for write-heavy paths

Frequência: HighFormulaicidade: FixedPrioridade de aquisição: Recognition firstPrioridade de output: BothTag de espaçamento: Medium-term

Examples

import json import redis from sqlalchemy import create_engine, text cache = redis.Redis(host='localhost', port=6379) engine = create_engine('postgresql://user:pass@localhost/app') def get_user_profile(user_id: int): cache_key = f'user:{user_id}' cached = cache.get(cache_key) if cached is not None: return json.loads(cached) with engine.connect() as conn: row = conn.execute( text('SELECT id, name, email FROM users WHERE id = :uid'), {'uid': user_id}, ).first() if row is None: return None profile = {'id': row.id, 'name': row.name, 'email': row.email} cache.setex(cache_key, 300, json.dumps(profile)) return profile

import json import redis cache = redis.Redis(host='localhost', port=6379) def get_product_catalog(category: str): cache_key = f'catalog:{category}' cached_items = cache.get(cache_key) if cached_items is not None: return json.loads(cached_items) items = fetch_products_from_db(category) cache.setex(cache_key, 600, json.dumps(items)) return items def update_product_price(product_id: int, new_price: float): db.execute( 'UPDATE products SET price = ? WHERE id = ?', (new_price, product_id), ) cache.delete(f'product:{product_id}') for category in get_categories_for(product_id): cache.delete(f'catalog:{category}')

import json import time import redis cache = redis.Redis(host='localhost', port=6379) LOCK_TTL = 5 def get_dashboard_metrics(tenant_id: str): key = f'metrics:{tenant_id}' value = cache.get(key) if value is not None: return json.loads(value) lock_key = f'lock:{key}' if cache.set(lock_key, '1', nx=True, ex=LOCK_TTL): try: metrics = compute_metrics_from_store(tenant_id) cache.setex(key, 60, json.dumps(metrics)) return metrics finally: cache.delete(lock_key) time.sleep(0.1) return get_dashboard_metrics(tenant_id)