Connect Cachee to your database's change stream. When a row changes, the cache key invalidates automatically. No code. No TTLs. No stale data.
Cache invalidation is famously one of the hardest problems in computer science. And yet every engineering team solves it from scratch, every time, with brittle custom code.
A user updates their profile. The database row changes. Now you need every cache key that references that user to reflect the new data. Immediately. Across every service.
So your team builds an invalidation pipeline. Maybe it starts with a webhook. The application writes to the database, then fires a POST to an invalidation endpoint. But what if the webhook fails? What if the application crashes between the write and the webhook call? You add retry logic, a dead-letter queue, monitoring alerts.
Or you go the pub/sub route. Every write publishes to a Kafka topic or Redis stream. Consumers subscribe, parse the event, figure out which cache keys to invalidate. Now you have a distributed system to maintain. Schema changes break your consumers. Partitioning decisions affect ordering guarantees. Each team wires it up differently.
Some teams skip the complexity and just set short TTLs. Five seconds. Thirty seconds. A minute. The cache works, but you serve stale data for the entire TTL window. For pricing data, account balances, or inventory counts, "eventually consistent within 30 seconds" is not acceptable.
The worst part: every approach requires application-level code changes. Your developers become the invalidation layer. Every new feature that writes to the database needs corresponding invalidation logic. Miss a key? Stale data. Fire an event twice? Thundering herd. Change a table schema? Update every consumer.
This is not an engineering problem that should exist. Your database already knows exactly what changed. The only question is whether anything is listening.
Your database already records every change in its write-ahead log. Cachee reads that log, maps each change to the affected cache keys, and evicts them instantly. No application code involved.
Cachee's CDC engine connects to your database as a logical replication subscriber. For PostgreSQL, it creates a replication slot and reads the WAL (Write-Ahead Log) directly. For MySQL, it attaches to the binlog stream. The database itself is the source of truth for what changed.
This means Cachee sees every change, regardless of which application, migration script, or admin console made it. There is no possibility of a write happening without the cache knowing. The WAL is the database's own internal record. It cannot be skipped, lost, or arrive out of order.
You tell Cachee which tables map to which cache key patterns using a simple declarative syntax. When the CDC engine sees a change to a mapped table, it constructs the affected cache key from the row data and evicts it from L1 immediately.
Key mapping supports wildcards, composite keys, and column-level filtering. If you only want to invalidate when specific columns change (e.g., price but not last_viewed_at), you can specify exactly that. This eliminates unnecessary cache churn from non-material column updates.
Once mapped, every change to the table triggers automatic invalidation. No application code, no webhook endpoints, no pub/sub consumers. The database tells the cache what changed. Learn more about how this integrates with predictive caching to pre-warm the replacement value before the next read.
Each connector is purpose-built for the database's native change stream protocol. No generic CDC middleware, no Debezium dependency, no Kafka cluster required.
pgoutput plugin. Reads the WAL in real time with transaction-level consistency. Supports PostgreSQL 12+ and all managed variants including RDS, Aurora, Cloud SQL, and Supabase. Zero performance impact on your primary instance.binlog_format=ROW.NEW_AND_OLD_IMAGES events to determine which fields changed and whether invalidation is needed. Supports global tables, on-demand mode, and DAX integration for a fully serverless CDC pipeline.MongoDB change streams, CockroachDB changefeeds, and SQL Server CDC are on the roadmap. Contact us if you need a specific database supported.
Every alternative requires application-level code. CDC does not. Here is what you can delete from your codebase after enabling CDC auto-invalidation.
| Approach | Manual Invalidation | CDC Auto-Invalidation (Cachee) |
|---|---|---|
| Setup Effort | Weeks of engineering per service | One CDC MAP command per table |
| Code Changes | Every write path needs invalidation logic | Zero application code |
| Stale Data Window | TTL-dependent (seconds to minutes) | < 1ms from commit |
| Missed Invalidations | Common (webhook failures, race conditions) | Impossible (WAL is authoritative) |
| Infrastructure | Kafka / SQS / Redis Pub/Sub / webhooks | Direct WAL connection, no middleware |
| Maintenance Burden | Schema changes break consumers | Self-healing, schema-aware |
| Coverage | Only changes made through your app | Every change, regardless of source |
| Ordering Guarantees | Depends on queue configuration | Transaction-order guaranteed by WAL |
Instead of building and maintaining an entire invalidation pipeline, you declare the mapping between your database tables and cache key patterns. Cachee handles the rest. When a row in the mapped table changes, the corresponding cache key is evicted from L1 before the next read can reach it.
Compare this to the alternative: a Kafka cluster, Debezium connectors, consumer applications, dead-letter queues, monitoring dashboards, and invalidation logic scattered across every microservice. CDC auto-invalidation replaces all of it with three lines in your Cachee config. See our full comparison page for more details.
CDC auto-invalidation is most valuable where stale data has real business consequences. These are the use cases where the difference between "eventually consistent" and "immediately consistent" matters.
CDC auto-invalidation layers on top of Cachee's full caching platform. Pair it with predictive pre-warming so evicted keys are repopulated before the next request arrives.
Invalidation alone leaves a gap. The key is evicted, but the next read still hits the origin. Cachee closes the gap by coupling CDC invalidation with immediate re-population.
Explore cache warming strategies for more on how Cachee pre-populates evicted keys from multiple origin sources.
One CDC MAP command replaces weeks of invalidation engineering. Connect your database, declare your key mappings, and never serve stale data again.