🗄️ Database Caching – Practical Explanation
Database caching is the practice of storing frequently accessed data (like query results or computed values) in a faster, temporary storage layer (like memory) to reduce database load and speed up response times.
⚙️ How It Works
Instead of hitting the DB every time:
-
App checks the cache for the required data.
-
If cache hit → return the data immediately.
-
If cache miss → fetch from DB → store in cache → return to client.
🔍 Example
-
Query:
SELECT * FROM products WHERE id=42 -
First time: Fetches from DB → stores in Redis.
-
Next time: Checks Redis → returns instantly.
🧠 Types of Database Caching
| Type | What It Stores | Example |
|---|---|---|
| Query result cache | Full SQL result sets | SELECT queries |
| Object/Entity cache | App-level data objects | ORM entities (Hibernate, Sequelize) |
| Key-value cache | Custom app data | product_42 → { id: 42, name: "Shoes" } |
| Materialized views | Precomputed query results | Stored in DB but refreshed manually or on schedule |
🚀 Tools Used
-
In-memory stores:
-
Redis (most popular)
-
Memcached (simpler, faster for small data)
-
-
ORM-level cache:
-
Hibernate 2nd-level cache
-
Sequelize, Prisma with custom cache layers
-
-
Built-in DB caches:
-
MySQL query cache (deprecated in 8.0)
-
PostgreSQL shared buffers
-
📦 Cache Patterns
| Pattern | How It Works |
|---|---|
| Read-through | App reads from cache; on miss, fetches from DB and stores in cache. |
| Write-through | App writes to cache and DB simultaneously. |
| Write-behind | App writes to cache → cache writes to DB later (async). |
| Cache-aside (Lazy loading) | App manually checks cache → populates on miss (most common). |
🔁 Invalidation Strategies
To prevent stale data:
-
Time-based: TTL (e.g., 60 seconds)
-
Manual: Delete/Update cache on write
-
Versioning: Use versioned keys (
user_123_v2) -
Event-based: Invalidate when DB change events occur
✅ Benefits
-
⚡ Up to 10x–100x faster than DB reads
-
📉 Less pressure on the DB (especially with read-heavy apps)
-
📈 Scales better for high-traffic systems
⚠️ Pitfalls
-
❌ Stale data if cache isn’t updated
-
📊 Memory overhead
-
🐛 Race conditions when writes happen fast
-
🕵️ Hard to debug if data inconsistencies arise
🧪 Real-World Example
In an e-commerce app:
-
Product details are cached by product ID in Redis.
-
When inventory or price changes → you invalidate the cache.
-
On next read, data is fresh again.