Change Relay

The in-memory app cache implementation in core package need to receive the updates made on some data in database.

The type of data app cache interested in are mostly static type of data. The tables that don't get updated too frequently.

These tables have a trigger attached to them that will execute on insert, delete and update operations. Each time trigger runs c_event_id_seq sequence counter incremented and a message is published via pg_notify to data_changed channel.

Database update messages

Published message have the following fields.

Field	Type	Desc
e_id	number	Global event id
e_ts	number	Event timestamp in ms
source_name	string	Code assigned to table

This in not the only type of message some services might only be interested in updates made on some specific entry in a table. For these type of updates additionally an identifier field is attached to pg_notify message. As the name suggests identifier field has some data that helps us identify the updated row.

Field	Type	Desc
e_id	number	Global event id
e_ts	number	Event timestamp in ms
source_name	string	Code assigned to table
identifier	string	Row identifier

How do the consumer services receive messages?

As we said, these messages streamed from database and services need to receive these messages. But as the number of services rise, we may exhaust the connection pool of database. Therefore, database only listened from change relay and pg_notify messages reformatted and published via websocket for use of other services.

This way, only handful of pg_notify socket connections opened to database.

Published update messages

Change relay publishes the following messages.

Messages with identifier has version numbers for each row.

{
  "label": "parameters",
  "data": {
    "all": {
      "v": 32541507,
      "ts": 1756894059770
    },
    "SMSPROVIDERCONFIG": {
      "v": 31957748,
      "ts": 1756245549754
    },
    "WAFCONFIG": {
      "v": 32541507,
      "ts": 1756894059770
    },
    ...
  }
}

Messages without identifier have only one version number.

{
  "label": "resource",
  "data": {
    "all": {
      "v": 32544748,
      "ts": 1756897692358
    }
  }
}

App cache listens these messages and stores the version numbers in memory. If an increment is detected in an interested version number app cache will run its loader function to renew data it cached priorly.