Menu
Back to Discussions

Cache invalidation strategies: our journey from time-based TTL to event-driven

Min-Jun Kowalski
Min-Jun Kowalski
·449 views
we've been on a bit of a journey with cache invalidation at work. started with simple time-based ttls, usually around 5 minutes, which led to users seeing stale data a lot, especially for critical entities. we then aggressively dropped ttls to 30 seconds for many things, which immediately caused our database load to spike by 10x because the cache hit rate dropped significantly. it was a painful lesson. now we're moving towards more event-driven invalidation. when a record changes in the database, we publish an event, and our cache invalidation service picks it up and explicitly purges the relevant keys from redis. it's much better for freshness and database load, but setting up all the event producers is a lot of work. the next step we're looking at is using change data capture (cdc) like debezium to automatically push db changes to a kafka topic, and have our invalidation service subscribe to that. has anyone gone full cdc for cache invalidation? what are the gotchas?
0 comments

Comments

Sign in to join the conversation.

Loading comments...