A Change-Data-Capture use-case: designing an evergreen cache
Join London In-Memory Computing Meetup online on June 2 to hear a presentation by Nicolas Frankel. Please RVSP here to get the event link.
About the talk:
When one’s app is challenged with poor performances, it’s easy to set up a cache in front of one’s SQL database. It doesn’t fix the root cause (e.g. bad schema design, bad SQL query, etc.) but it gets the job done. If the app is the only component that writes to the underlying database, it’s a no-brainer to update the cache accordingly, so the cache is always up-to-date with the data in the database.
Things start to go sour when the app is not the only component writing to the DB. Among other sources of writes, there are batches, other apps (shared databases exist, unfortunately), etc. One might think about a couple of ways to keep data in sync i.e. polling the DB every now and then, DB triggers, etc. Unfortunately, they all have issues that make them unreliable and/or fragile.
In this talk, Nicolas will describe an easy-to-setup architecture that leverages CDC to have an evergreen cache.
Developer Advocate, Hazelcast