Caching and Performance

🚀 NoSQL Caching & Performance: The Speed Kitchen

Imagine you’re running a super busy restaurant. How do you serve food FAST without making customers wait forever?

🍳 The Big Picture: Why Caching Matters

Think of your database as a giant freezer in the basement. Every time someone orders food, you have to run downstairs, dig through the freezer, find the item, and bring it back up.

That’s SLOW!

Now imagine you have a small fridge right next to you in the kitchen. You keep the most popular items there. When someone orders a burger? BAM! It’s right there. No running to the basement.

That small fridge = Your CACHE The big freezer = Your DATABASE

🎯 Caching Patterns: Different Ways to Use Your Kitchen Fridge

1. Cache-Aside (Lazy Loading) 🦥

The “Get It When You Need It” Pattern

Customer orders → Check fridge first
├─ Found? → Serve it! ✅
└─ Not found? → Get from freezer,
                put in fridge,
                then serve

Real Example:

// Looking for user profile
data = cache.get("user:123")
if (data == null) {
  data = database.find("user:123")
  cache.set("user:123", data)
}
return data

When to use: Most common pattern. Works great for READ-HEAVY apps.

2. Write-Through 📝

The “Always Keep Fridge Updated” Pattern

When you get new ingredients, you put them in BOTH the fridge AND the freezer at the same time.

graph TD
    A["New Data Arrives"] --> B["Write to Cache"]
    B --> C["Write to Database"]
    C --> D["Done! Both Updated"]

Simple Example:

function saveUser(user) {
  cache.set("user:" + user.id, user)
  database.save(user)
}

Benefit: Cache is ALWAYS fresh! Cost: Writes are a bit slower.

3. Write-Behind (Write-Back) 📦

The “Update Later” Pattern

Put new stuff in the fridge NOW. Update the freezer LATER when you’re not busy.

Data arrives → Save to cache → Done! (fast!)
              ↓
        [Background job]
              ↓
        Update database later

When to use: When you need SUPER FAST writes and can wait a bit for database updates.

⚠️ Warning: If your fridge breaks before updating the freezer, you lose data!

4. Read-Through 📖

The “Automatic Fetch” Pattern

Your cache is SMART. When something isn’t there, it automatically goes to the database for you.

// You just ask for data
// Cache handles everything!
data = smartCache.get("user:123")
// If not in cache, it fetches
// from database automatically

🗑️ Cache Invalidation: When to Throw Out Old Food

“There are only two hard things in computer science: cache invalidation and naming things.” — Phil Karlton

Old food goes bad. Old cached data becomes stale. You need strategies to keep things fresh!

Strategy 1: Time-To-Live (TTL) ⏰

Set an expiration date!

// This data disappears after 5 minutes
cache.set("weather", data, ttl=300)

Like milk: Even if it looks fine, throw it out after the expiration date.

Strategy 2: Event-Based Invalidation 🎯

When data changes, delete the cached version.

function updateUserEmail(userId, newEmail) {
  database.update(userId, newEmail)
  cache.delete("user:" + userId) // Gone!
}

Like: When you buy fresh bread, throw out the old bread.

Strategy 3: Version Tags 🏷️

Give each cached item a version number.

user:123:v1 → Old data
user:123:v2 → New data (use this!)

When data updates, create a new version. Old versions naturally become unused.

The Stale Data Problem 🤢

What happens if you serve old data?

Rule: The more important the data, the shorter the cache time!

⚡ In-Memory Databases: The Speed Machines

What Are They?

Regular databases store data on hard drives (slow). In-memory databases store data in RAM (SUPER FAST).

Speed comparison:

Hard Drive: 🚗 Driving to work (10ms)
RAM:        🚀 Teleporting! (0.1ms)

Popular In-Memory Databases

Redis 🔴

• The most popular choice
• Stores key-value pairs
• Great for caching, sessions, leaderboards

// Redis example
redis.set("score:player1", 9500)
score = redis.get("score:player1") // INSTANT!

Memcached 🟢

• Simple and blazing fast
• Best for basic caching
• Used by Facebook, Twitter

When to Use In-Memory Databases?

✅ Perfect for:

• Session storage (who’s logged in?)
• Real-time leaderboards
• Shopping cart data
• Rate limiting
• Temporary data

❌ Not great for:

• Primary database (RAM is expensive!)
• Data you can’t afford to lose
• Huge datasets

🏎️ Latency Optimization: Making Everything FASTER

Latency = How long you wait for data

The Speed Pyramid

graph TD
    A["CPU Cache: 1 nanosecond"] --> B["RAM: 100 nanoseconds"]
    B --> C["SSD: 100,000 nanoseconds"]
    C --> D["Network: 1,000,000+ nanoseconds"]

Goal: Keep data as HIGH on this pyramid as possible!

Optimization Techniques

1. Keep Data Close 📍

Put your cache servers NEAR your users.

• User in Tokyo? Cache in Tokyo.
• User in New York? Cache in New York.

2. Batch Operations 📦

Instead of:

get user:1  → wait
get user:2  → wait
get user:3  → wait
Total: 30ms

Do this:

get user:1, user:2, user:3 → wait once
Total: 10ms

3. Compress Data 🗜️

Smaller data = Faster transfer

// Instead of storing full JSON
cache.set("user:123", compress(data))

4. Connection Pooling 🏊

Keep database connections OPEN and ready. Like keeping the fridge door… actually, don’t do that with real fridges! 😄

But for databases, keeping connections ready saves the time of opening new ones.

📚 Read-Heavy Workloads: Lots of People Looking!

Read-heavy = Many people reading, few people writing Examples: News sites, Wikipedia, product catalogs

Strategy: Cache Aggressively! 🎯

graph TD
    A["100 Users Request Same Page"] --> B{Cache Hit?}
    B -->|Yes| C["1 Cache Read"]
    B -->|No| D["1 Database Read"]
    D --> E["Store in Cache"]
    E --> C

Without cache: 100 database queries 😱 With cache: 1 database query + 99 cache hits 🎉

Best Practices

1. Long TTL - Data doesn’t change often? Cache it for hours!
2. Read Replicas - Make copies of your database just for reading
3. CDN for Static Content - Images, CSS, JS served from edge servers

// Product catalog - rarely changes
cache.set("products:all", data, ttl=3600) // 1 hour

✍️ Write-Heavy Workloads: Lots of People Saving!

Write-heavy = Many people writing data Examples: Chat apps, IoT sensors, logging systems

The Challenge

Every write might need to:

1. Update the database
2. Invalidate/update the cache
3. Notify other servers

Strategy: Buffer and Batch 📝

graph TD
    A["Write 1"] --> B["Buffer"]
    C["Write 2"] --> B
    D["Write 3"] --> B
    B --> E["Single Batch Write to DB"]

Best Practices

1. Write-Behind Caching - Queue writes, process in batches
2. Append-Only Logs - Faster than random updates
3. Eventually Consistent - Accept small delays in sync

// Logging system - write-behind
logBuffer.add(logEntry)
// Every 1000 entries or 5 seconds:
// → Flush buffer to database

🔄 Mixed Workloads: Reading AND Writing!

Mixed = Sometimes lots of reads, sometimes lots of writes Examples: Social media, e-commerce during sales

The Balancing Act

Morning: 80% reads, 20% writes (browsing)
Lunch:   50% reads, 50% writes (posting)
Night:   70% reads, 30% writes (scrolling)

Strategy: Adaptive Caching 🎭

graph TD
    A["Monitor Traffic Pattern"] --> B{More Reads?}
    B -->|Yes| C["Aggressive Caching"]
    B -->|No| D["Quick Cache Invalidation"]
    C --> E["Longer TTL"]
    D --> F["Shorter TTL"]

Best Practices

1. Segment Your Cache - Different rules for different data

   • User profiles: Long cache (read-heavy)
   • Shopping cart: Short/no cache (write-heavy)

2. Hot/Cold Data Separation

   • Hot data (popular posts): Keep in fast cache
   • Cold data (old posts): Store in database

3. Prioritize Consistency Where Needed

   • Bank balance: Always fresh
   • Like count: Can be 30 seconds old

// Different caching strategies
cache.set("user:profile", data, ttl=600)  // 10 min
cache.set("post:likes", count, ttl=30)    // 30 sec
cache.set("cart:" + id, cart, ttl=0)      // no cache

🧠 Quick Summary: The Restaurant Kitchen Rules

🌟 Your Caching Journey

Level 1: Start with Cache-Aside + TTL Level 2: Add in-memory cache (Redis) Level 3: Optimize for your specific workload Level 4: Build adaptive caching systems

Remember: A well-cached system can handle 100x more traffic!

Now go make your databases FAST! 🚀

Next: Try the interactive simulation to see caching in action!