A Change-Data-Capture use-case: designing an evergreen cache
summary
Shows a concrete CDC pipeline that tails the MySQL binlog (via a Debezium-style connector), maps row changes to key/value entries and writes them into a Hazelcast map using Hazelcast Jet, producing an evergreen cache that reflects external writes. Demo proves the cache is stale while the pipeline is stopped and immediately in sync after the job starts, so the claim — replace fragile triggers/polling with log-based CDC for reliable cache updates — is demonstrated end to end.
AI-written summary · about
chapters (20)
- 0:00Start
- 1:40The caching trade-off
- 3:00The initial state
- 4:17Cache invalidation
- 4:41Cache eviction vs Time-To-Live
- 6:56Choosing the "correct" TTL
- 8:48External process
- 10:13The example of MySQL: User-defined function
- 12:33Change-Data-Capture
- 13:20CDC implementation options
- 13:53"Turning the database inside out" - Martin Kleppman
- 16:16Reasons for the log
- 16:45Sample MySQL binlog
- 18:25Debezium connector plugins
- 19:08Hazelcast Jet
- 19:33Jet overview
- 19:59Deployment modes
- 21:04Pipeline
- 21:56Back to our use-case
- 30:14Recap
related talks
32mA Change-Data-Capture use-case: designing an evergreen cache
41mA Change-Data-Capture use-case: designing an evergreen cache
01mA Change-Data-Capture use-case: designing an evergreen cache
23mChange Data Capture: A RabbitMQ and Debezium Approach
01h 09mOpen-source Change Data Capture With Debezium
41mStreaming your database - Easier said than done?
39mDeep Dive on Using YugabyteDB's Change Data Capture Connector
35mChange Data Capture: The Magic Wand We Forgot #bbuzz