Stratégies avancées d’invalidation du cache

You've learned about caching to boost performance and reduce costs in LLM apps. But what happens when the original data changes?

Cache invalidation is the process of removing or updating stale (outdated) data from the cache. It's crucial for ensuring your RAG system provides fresh, accurate information.

Imagine your RAG system caches a document. If that document is updated in your source database but the cache isn't refreshed, users will get old information.

This is the stale data problem. Finding the right balance between serving fast cached data and ensuring its freshness is a key challenge in production LLM systems.

The simplest invalidation method is Time-to-Live (TTL). Each cached item is given a lifespan. Once this time expires, the item is automatically removed or marked as stale.

• Example: A news article cached with a 1-hour TTL. After 1 hour, it's gone, and the next request fetches the latest version.

It's easy to implement but doesn't guarantee immediate freshness upon source data changes.

Most caching libraries and systems support TTL. Here's a conceptual look:

// Pseudocode for a cache with TTL
Cache.put("doc_id_123", document_content, ttl_seconds=3600)

// After 3600 seconds, 'doc_id_123' will be automatically removed
// or marked as expired from the cache.

When a request comes for an expired item, the system fetches it from the original source and recaches it with a new TTL.

For stricter freshness, event-driven invalidation is powerful. Instead of waiting for a TTL, the cache is explicitly invalidated when the source data changes.

This often involves a messaging system. When data is updated in the database, an 'update' event is published. The caching service subscribes to these events and invalidates the relevant cache entry.

Here's a common flow:

1. Data Update: Application updates data in the primary database.
2. Event Publish: The application (or a database trigger) publishes an event (e.g., 'document_123_updated') to a message queue (like Redis Pub/Sub, Kafka).
3. Cache Listener: A service listening to the queue receives the event.
4. Cache Invalidate: The service then removes or updates 'document_123' in the cache.

This ensures the cache is updated almost immediately after the source data changes.

The write-through pattern focuses on consistency. When data is written, it's simultaneously written to both the cache and the primary data store (e.g., database).

This means the cache is always consistent with the database at the time of writing. There's no separate invalidation step needed for new or updated data if all writes go through the cache.

Consider an update operation with write-through:

// Pseudocode for write-through cache
function updateDocument(id, newContent):
  database.update(id, newContent)
  cache.put(id, newContent) // Cache is updated immediately
  return success

The downside is that write operations become slower because they have to complete two writes instead of one.

A related pattern is write-back (or write-behind). Here, data is written only to the cache first, and then asynchronously written to the primary data store later.

• Pros: Very fast write operations.
• Cons: Data loss risk if the cache fails before syncing. Less immediate consistency.

Write-back is typically for high-performance scenarios where some data loss or eventual consistency is acceptable.

Which invalidation strategy is best depends on your application's needs:

• TTL: Simple, good for data that can be slightly stale (e.g., blog posts, low-traffic reference docs).
• Event-Driven: Best for high freshness requirements (e.g., financial data, frequently updated critical documents). Requires more infrastructure.
• Write-Through: Guarantees immediate consistency on writes. Suitable for data where read-after-write must always be fresh, even if writes are slightly slower.

Great job! In this lesson, we explored advanced strategies to keep your RAG system's cache fresh and accurate:

• Time-to-Live (TTL): Simple, time-based expiration.
• Event-Driven Invalidation: Reacts to data changes, offering high freshness.
• Write-Through Caching: Updates cache and database simultaneously for consistency.
• Write-Back Caching: Optimizes write speed by writing to cache first, then asynchronously to DB.

Choosing the right strategy depends on your application's specific needs for performance vs. consistency.