Un cas d'utilisation de CDC : un cache toujours à jour

Lorsque votre application affiche de mauvaises performances, il est facile de configurer un cache en façade de votre base de données SQL. Ca ne corrige pas la cause principale (par exemple, une mauvaise conception de schéma, une mauvaise requête SQL, etc.) mais ca permet de continuer à utiliser l'application de manière norminale . Si cette dernière est le seul composant qui écrit dans la base de données sous-jacente, il est facile de mettre à jour le cache en conséquence, afin que celui-ci soit toujours à jour avec les données de la base.

La situation se complique lorsque l'application n'est pas le seul composant à écrire. Parmi les autres sources d'écritures, on peut citer les traitements par lot, d'autres applications (des bases de données partagées existent malheureusement), etc. On oeut imaginer plusieurs manières pour conserver les données synchronisées : interroger la base de données de temps en temps, des triggers, etc. Malheureusement, toutes ces approches ont des problèmes qui les rendent peu fiables et / ou fragiles.

Vous avez peut-être déjà entendu parler de Change-Data-Capture. CDC a été décrit par Martin Kleppmann comme turning the database inside out : cela signifie que la base de données peut être utilisée pour envoyer des événements de modification (SELECT, DELETE et UPDATE) auxquels on peut s'abonner. A l'opposé de Event Sourcing qui agrège les événements pour produire l'état, CDC consiste à extraire les événements de l'état. Une fois CDC implémenté, on peut s'abonner aux événements et mettre à jour le cache en conséquence. Cependant, CDC en est à ses débuts et les implémentations sont assez spécifiques.

Dans cette présentation, je décrirai une architecture typique qui exploite CDC pour bénéficier d'un cache toujours à jour.