TIS - CQRS Dreaming

All the leaves are brown

With NI and Healthcare Sciences coming onto TIS, its now a good time to look at what we’ve got (and done) to see if its fit for purpose and meets requirements.

This document assumes you’ve listened to the team sharing on whats been done already in terms of ACL and the possible (short term) implementations without ACL.

I’ve been for a walk, on a winters day

Below is a high level diagram on what I (PaulH) see what the implementation could be like if we went down a CQRS route

For people that don’t know what CQRS is (Command, Query Responsibility Segregation) is an application architecture style that splits the read and writing of data. In a typical application, both the read and writes of data would be handled by that same application. In CQRS, reads and writes don’t necessarily come/go to the same application (this doesn’t mean same instance, it means two distinct apps/services)

I’ll be safe and warm, If I was in LA

In this instance, we would have a canonical data store, which has all the data but no clients (users) will have any read access to. This data store will be managed by TIS services that receive write requests (commands) from front end applications (you wouldn’t need to modify TIS as it is right now but you would need to block read access to these services connected to this DB).

Once an update occurs to the datastore, messages are then sent to a messaging system for a number of consumers to process. Here we would have a TIS consumer and NI consumer. These consumers will check if TIS/NI should hold this data, if so, then the record would then be updated/removed in the READ ONLY (to a service) DB. This is also a point in which the consumer should transform the data so that its in the correct format for the service/user.

The READ ONLY DB’s will have the same (TIS) services attached but with DB users that only have read access.

California Dreaming

The diagram above looks as though there are multiple instances of the DB. This however doesn’t need to be the case. Like the existing system, you can multiple schema’s within the DB instance. So in this case, you would have 2 read only schema’s (TIS/NI) and 1 write schema (Canonical) all on the same database server.

In terms of service deployment, reference, profile etc, these all can be as is (one version for write and the other for read) where it gets complicated is where the data differs, so TCS will need 2 instances of read services (TIS/NI) and 1 for write.

If however, NI or TIS features will need to diverge, this will allow you for fork TCS and replace those 2 read instances with ease

The complication in this type of architecture would be to make the frontend apps aware that the writes need to go elsewhere and the added latency to the change of data

Events store. One thing that usually goes hand in hand with CQRS is the usage of events store. I’ve purposely not added this in here as I think it adds additional complexity. Most systems also use something like Kafka for an events store (which we don’t use) / messaging platform but since we have rabbit ….