DOC-5851 added initial tutorial text (needs a lot of work)

Author: andy-stark-redis

content/develop/use-cases/_index.md

@@ -0,0 +1,5 @@
+---
+title: Use cases
+description: Learn how to develop with Redis
+linkTitle: Use cases
+---

content/develop/use-cases/cache-aside/_index.md

@@ -0,0 +1,259 @@
+---
+description: Learn how to implement the cache-aside pattern with Redis for improved application performance
+linkTitle: Cache-Aside Pattern
+title: Cache-Aside Pattern Tutorial
+weight: 1
+---
+
+The **cache-aside pattern** (also called "lazy loading") is a caching strategy where your application manages both the cache and the underlying data store. This tutorial teaches you how to implement this pattern with Redis to improve application performance.
+
+## What is the Cache-Aside Pattern?
+
+The cache-aside pattern works by:
+
+1. **Check the cache** - When your application needs data, it first checks Redis
+2. **Cache miss** - If the data isn't cached, fetch it from your data store (database, API, etc.)
+3. **Store in cache** - Save the data in Redis with a time-to-live (TTL)
+4. **Return the data** - Send the data to the client
+5. **Cache hit** - On subsequent requests, return the cached data immediately
+
+```
+Request for Data
+    ↓
+Check Redis Cache
+    ↓
+    ├─ Cache Hit → Return cached value (fast!)
+    │
+    └─ Cache Miss
+        ↓
+        Fetch from Data Store
+        ↓
+        Store in Redis with TTL
+        ↓
+        Return value
+```
+
+## When to Use Cache-Aside
+
+Cache-aside is ideal for:
+
+- **Read-heavy workloads** - Most requests are reads, not writes
+- **Tolerable staleness** - Your data can be slightly out of date
+- **Heterogeneous data** - Different data types with varying access patterns
+- **Resilient systems** - Cache failures shouldn't break your application
+
+**Don't use cache-aside for:**
+- Write-heavy workloads (use write-through or write-behind instead)
+- Data requiring strict consistency
+- Small datasets that fit entirely in memory
+
+## Basic Implementation
+
+Here's a simple cache-aside implementation in Python:
+
+```python
+import redis
+import json
+
+# Connect to Redis
+r = redis.Redis(host='localhost', port=6379, decode_responses=True)
+
+def get_user(user_id):
+    """Get user data with cache-aside pattern."""
+    cache_key = f'user:{user_id}'
+    
+    # Step 1: Check cache
+    cached_user = r.get(cache_key)
+    if cached_user:
+        print(f"Cache hit for {cache_key}")
+        return json.loads(cached_user)
+    
+    # Step 2: Cache miss - fetch from database
+    print(f"Cache miss for {cache_key}")
+    user = fetch_from_database(user_id)  # Your database query
+    
+    # Step 3: Store in cache with 1-hour TTL
+    r.setex(cache_key, 3600, json.dumps(user))
+    
+    # Step 4: Return data
+    return user
+```
+
+## Cache Invalidation
+
+When data changes, you need to invalidate the cache to prevent stale data:
+
+```python
+def update_user(user_id, new_data):
+    """Update user and invalidate cache."""
+    # Update database
+    update_database(user_id, new_data)
+    
+    # Invalidate cache
+    cache_key = f'user:{user_id}'
+    r.delete(cache_key)
+    
+    # Next request will fetch fresh data
+```
+
+### Pattern-Based Invalidation
+
+Invalidate multiple related keys at once:
+
+```python
+def invalidate_user_cache(user_id):
+    """Invalidate all cache keys for a user."""
+    # Delete all keys matching pattern
+    pattern = f'user:{user_id}:*'
+    for key in r.scan_iter(match=pattern):
+        r.delete(key)
+```
+
+## TTL Management
+
+Set appropriate time-to-live values for different data types:
+
+```python
+# Short TTL for frequently changing data (5 minutes)
+r.setex('user:session:123', 300, session_data)
+
+# Medium TTL for user profiles (1 hour)
+r.setex('user:profile:456', 3600, profile_data)
+
+# Long TTL for reference data (24 hours)
+r.setex('product:catalog', 86400, catalog_data)
+```
+
+## Error Handling
+
+Always handle cache failures gracefully:
+
+```python
+def get_user_safe(user_id):
+    """Get user with fallback to database on cache failure."""
+    try:
+        cache_key = f'user:{user_id}'
+        cached_user = r.get(cache_key)
+        if cached_user:
+            return json.loads(cached_user)
+    except redis.ConnectionError:
+        print("Redis unavailable, falling back to database")
+    except Exception as e:
+        print(f"Cache error: {e}")
+    
+    # Fallback: fetch from database
+    return fetch_from_database(user_id)
+```
+
+## Performance Metrics
+
+Monitor cache effectiveness with hit/miss ratios:
+
+```python
+class CacheMetrics:
+    def __init__(self):
+        self.hits = 0
+        self.misses = 0
+    
+    def record_hit(self):
+        self.hits += 1
+    
+    def record_miss(self):
+        self.misses += 1
+    
+    def hit_ratio(self):
+        total = self.hits + self.misses
+        return self.hits / total if total > 0 else 0
+
+metrics = CacheMetrics()
+
+def get_user_tracked(user_id):
+    cache_key = f'user:{user_id}'
+    cached_user = r.get(cache_key)
+    
+    if cached_user:
+        metrics.record_hit()
+        return json.loads(cached_user)
+    
+    metrics.record_miss()
+    user = fetch_from_database(user_id)
+    r.setex(cache_key, 3600, json.dumps(user))
+    return user
+
+# Check performance
+print(f"Hit ratio: {metrics.hit_ratio():.2%}")
+```
+
+## Best Practices
+
+1. **Use appropriate TTLs** - Balance freshness vs. cache efficiency
+2. **Handle cache failures** - Always fall back to the data store
+3. **Monitor hit ratios** - Aim for 80%+ hit ratio for optimal performance
+4. **Invalidate strategically** - Use pattern-based invalidation for related data
+5. **Compress large values** - Use gzip for large cached objects
+6. **Use key prefixes** - Organize keys by data type (e.g., `user:`, `product:`)
+7. **Implement retry logic** - Handle transient Redis failures gracefully
+
+## Common Pitfalls
+
+### Cache Stampede
+When a popular cache entry expires, many concurrent requests hit the database:
+
+```python
+# Problem: Multiple requests fetch same data simultaneously
+# Solution: Use locks or probabilistic early expiration
+def get_user_with_lock(user_id):
+    cache_key = f'user:{user_id}'
+    lock_key = f'{cache_key}:lock'
+    
+    cached_user = r.get(cache_key)
+    if cached_user:
+        return json.loads(cached_user)
+    
+    # Try to acquire lock
+    if r.set(lock_key, '1', nx=True, ex=10):
+        try:
+            user = fetch_from_database(user_id)
+            r.setex(cache_key, 3600, json.dumps(user))
+            return user
+        finally:
+            r.delete(lock_key)
+    else:
+        # Wait for lock holder to populate cache
+        time.sleep(0.1)
+        return get_user_with_lock(user_id)
+```
+
+### Null Value Caching
+Cache null values to prevent repeated database queries:
+
+```python
+def get_user_with_null_cache(user_id):
+    cache_key = f'user:{user_id}'
+    cached = r.get(cache_key)
+    
+    if cached == 'NULL':
+        return None  # User doesn't exist
+    
+    if cached:
+        return json.loads(cached)
+    
+    user = fetch_from_database(user_id)
+    
+    if user is None:
+        r.setex(cache_key, 300, 'NULL')  # Cache null for 5 minutes
+    else:
+        r.setex(cache_key, 3600, json.dumps(user))
+    
+    return user
+```
+
+## Next Steps
+
+- Explore [Redis data types]({{< relref "/develop/data-types" >}}) for different caching scenarios
+- Implement [Redis Streams]({{< relref "/develop/data-types/streams" >}}) for event logging
+
+## Additional Resources
+
+- [Redis Python Client Documentation](https://redis-py.readthedocs.io/)
+- [Redis Commands Reference]({{< relref "/commands" >}})