Notifications and Cache Maintenance

Now that we have the basic server-side infrastructure in place, where PostgreSQL is the server and the back-end application is a client, we can look into maintaining our twcache.counters cache in an event-driven fashion.

Cache and cache maintenance service

PostgreSQL LISTEN and NOTIFY support is perfect for maintaining a cache. Because notifications are only delivered to client connections that are listening at the moment of the notify call, our cache maintenance service must implement the following behavior in this exact order:

1. Connect to the PostgreSQL database we expect notifications from and issue the listen command.

2. Fetch the current values from their “single source of truth” and reset the cache with those computed values.

3. Process notifications as they come and update the in-memory cache, and once in a while, synchronize the in-memory cache to its materialized location, as per the cache invalidation policy.

The cache service can be implemented within the cache maintenance service. As an example, a cache server application might both process notifications and serve the current cache from memory over an HTTP API. The cache service might also be one of the popular cache solutions, such as Memcached or Redis.

Implementing cache maintenance service

In our example, we implement a cache maintenance service in Go, and the cache itself is maintained as a PostgreSQL table: