One of the architectural challenges we are facing on a project is ensuring data consistency over our microservice domains. We have two rules that we are trying hard to enforce: 1. Services cannot directly communicate with one another (primarily to reduce latency and prevent deadlocks) and 2. Each service only has direct access to its own database. The challenge is that there's a lot of data that we need from service to service.
For example, Users are associated with Customers, which live in the Customer Domain. However, our Jobs domain service needs to know what customers a user has access to. Ensuring that an update to the Customer Association in the Customer Domain flows into the Jobs domain is a key need.
Our current design has these updates flowing on a message queue. Basically, when Customer Domain updates a Customer Association, it drops a message on the queue and anything that cares about that change can read off that queue and update its database where relevant. This feels like a lot of stuff to maintain, though, as each domain now has to have code to listen to the MQ and process data where appropriate (and also code to push messages into the MQ).
An earlier design provided by a contractor included "Read Only Copies" of each relevant domain's database (so Jobs would have a readonly copy of the Customer Domain database), but because we're on MS SQL Server, we could not figure out a good way to create readonly slaves for those services that would be updated as the master was updated.
Are we missing something obvious here?