Cache-aside (sometimes called "lazy loading") is the most common caching pattern in the wild — and the one most developers implement without realizing it has a name. The application code, not the cache, owns the read/write logic. The cache is a dumb key-value store sitting next to your database.

The flow:

• Read: Check cache. If hit, return it. If miss, query the database, write the result to cache, return it.
• Write: Write to the database. Then invalidate (delete) the cache entry — don't update it.

Contrast this with read-through (the cache fetches from the DB itself) or write-through (the cache writes to the DB synchronously). Cache-aside keeps the cache stupid and the application smart.

Why delete instead of update on write? If two writers race, "last write wins" in the database may not match "last write wins" in the cache — you can end up with the cache holding stale data forever. Deleting forces the next read to repopulate from the source of truth. The tradeoff: the next reader pays the cache-miss tax.

Real example: A product page reads product:42 from Redis. Miss. App queries Postgres, gets the row, writes it back to Redis with a 5-minute TTL, returns it. Next 10,000 reads in the next 5 minutes are pure cache hits. When inventory changes, the inventory service deletes product:42. Next reader rebuilds it.

The pitfalls nobody warns you about:

• Thundering herd on miss: Cache entry expires, 500 concurrent requests all miss simultaneously, all 500 hammer the database. Mitigate with single-flight locks or "stale-while-revalidate" semantics.
• Negative caching: Cache the absence of a result too, or attackers can DoS your DB by requesting nonexistent IDs over and over.
• The delete-then-write race: Reader A misses, queries DB. Writer B updates DB, deletes cache. Reader A writes its now-stale value back. Bug. Fix with versioning or short TTLs as a safety net.

Rule of thumb: Set a TTL that's at most 10x the acceptable staleness window. If users can tolerate 30 seconds of stale data, TTL of 5 minutes is fine — the cache catches normal load and the TTL bounds your worst case if invalidation logic has a bug. Always have a TTL, even when you also invalidate explicitly. The TTL is your insurance policy against the invalidation bug you haven't found yet.

Cache-aside works when reads dominate writes (say, 100:1 or more) and brief staleness is acceptable. Skip it for write-heavy workloads or anything requiring strong consistency.