A Change-Data-Capture use-case: designing an evergreen cache | DevsDay.ru

A Change-Data-Capture use-case: designing an evergreen cache

Wix Kyiv

Зарегистрироваться на событие




Please notice:

* The meetup will be online and the talk will be in English.
* Link to the event will only be visible to people who RSVP.
* The online meetup will be held on July 9, 16:00, Israel Time Zone, GMT +3:00

// A Change-Data-Capture use-case: designing an evergreen cache - Nicolas Frankel

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.

You might have read about Change-Data-Capture before. It’s been described by Martin Kleppmann as turning the database inside out: it means the DB can send change events (SELECT, DELETE and UPDATE) that one can register to. Just opposite to Event Sourcing that aggregates events to produce state, CDC is about getting events out of states. Once CDC is implemented, one can subscribe to its events and update the cache accordingly. However, CDC is quite in its early stage, and implementations are quite specific.

In this talk, I’ll describe an easy-to-setup architecture that leverages CDC to have an evergreen cache.

// Bio - Nicolas Frankel
Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail, and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a teacher in universities and higher education schools, a trainer, and triples as a book author.

https://blog.frankel.ch/

Как нас найти:

https://wix.zoom.us/j/95381794961


Организатор: Wix Kyiv

We believe that knowledge sharing should be the cornerstone of our industry and hence created this community where people can share the things they learned about software engineering, design, leadership and scale.


Wix Kyiv creates a nurturing atmosphere for tech professionals and enthusiasts. We are here to to share ideas and run workshops and you are very welcome to become our active participant.

Join our Meetup group to follow our local events, workshops, and training.


Зарегистрироваться на событие


События в IT Киев


Please notice: * The meetup will be online and the talk will be in English.* Link to the event will only be visible to people who RSVP.* The online meetup will be held on July 9, 16:00, Israel Time Zone, GMT +3:00 // A Change-Data-Capture use-case: designing an evergreen cache - Nicolas Frankel 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. You might have read about Change-Data-Capture before. It’s been described by Martin Kleppmann as turning the database inside out: it means the DB can send change events (SELECT, DELETE and UPDATE) that one can register to. Just opposite to Event Sourcing that aggregates events to produce state, CDC is about getting events out of states. Once CDC is implemented, one can subscribe to its events and update the cache accordingly. However, CDC is quite in its early stage, and implementations are quite specific. In this talk, I’ll describe an easy-to-setup architecture that leverages CDC to have an evergreen cache. // Bio - Nicolas FrankelDeveloper Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail, and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a teacher in universities and higher education schools, a trainer, and triples as a book author. https://blog.frankel.ch/ Как нас найти:https://wix.zoom.us/j/95381794961 Организатор: Wix Kyiv We believe that knowledge sharing should be the cornerstone of our industry and hence created this community where people can share the things they learned about software engineering, design, leadership and scale. Wix Kyiv creates a nurturing atmosphere for tech professionals and enthusiasts. We are here to to share ideas and run workshops and you are very welcome to become our active participant. Join our Meetup group to follow our local events, workshops, and training.
2020-07-09T00:00:00.0000000
2020-07-09T00:00:00.0000000
A Change-Data-Capture use-case: designing an evergreen cache
Wix Kyiv
?.Trim()
A Change-Data-Capture use-case: designing an evergreen cache
Киевская область, г. Киев.