CQRS Read Model syncronization: right way to "query" the write models between microservices

Question

I'm trying to follow the database per read/write per microservice pattner with HTTP CQRS API.

following this example

Asset Microservice

Write Model:

• AssetWriteDb (mssql)
• Asset class/table

public class Asset
{
 public Guid AssetId {get;set;}
 public Guid ContractId {get;set;} //reference to contract of other microservice
 ...
}

Read Model

• AssetReadDb (mongodb)
• AssetAggregate class/collection

public class AssetAggregate
{
 public Guid AssetId {get;set;}
 public Guid ContractId {get;get;}
 public string ContractNumber {get;set;} //this comes from Contract Microservice
 ...
}

Contract Microservice

Write Model

• ContractWriteDb (mssql)
• Contract class/table

public class Contract
{
 public Guid ContractId {get;set;}
 public string ContractNumber {get;set;}
 ...
}

Read Model

• ContractReadDb (mongodb)
• ContractAggregate class/collection

public class ContractAggregate
{
 public Guid ContractId {get;set;}
 public string ContractNumber {get;set;}
 public int AssetCount {get;set;} //this comes from Asset microservice
 ...
}

---

Contract aggregate syncronization eventHandler example:

public class ContractAggregateHandler :
 IHandleMessage<ContractChangedEvent> // published from ContractWriteDb mssql repository
 IHandleMessage<AssetChangedEvent> // published from AssetWriteDb mssql repository 
{
 
 public async Task Handle(ContractChangedEvent message)
 {
   await _bus.Send(new RefreshContractAggregateCommand(message.ContractId));
 }

 public async Task Handle(AssetChangedEvent message)
 {
   //since the event contains only AssetId, I need to retrieve the data from the asset microservice. i have two options to obtain the contractId from asset microservice:

   //call the AssetApi microservice reading the AssetAggregate collection (mongodb)
   //var contractId = await _mediator.Send(new GetAssetContractIdQuery(message.AssetId);
   
   //call the AssetApi microservice reading the Asset table (sqlserver)
   //var contractId = await _mediator.Send(new GetAssetContractIdFromWriteDbQuery(message.AssetId);


   await _bus.Send(new RefreshContractAggregateCommand(contractId));
 }
}

Following the rule that Queries should always query the Read Model and Commands should always read and write the Write Model, what are the best practices to achive this?

in the first case (reading the mongodb asset read model), I think it's wrong: the AssetChanged event comes from the AssetWriteDb (sql server) and querying the read model is not safe. also, if I base the aggregates generation by other aggregates, I should listen the AssetAggregateRefreshedEvent, but this will create infinites loops between aggregates generation because the AssetAggregates will need to liaste the ContractAggregateRefreshedEvent that these operations will never ends.

in the second case, (reading the sql asset write model) I think it is the safest but I need to manage a lot of queries that are "wrong" because they are not following the rule "queries must get data from read model". That's why to avoid mistakes, I need to differentiate them using a different ending word like "FromWriteDbQuery"

there is a third option that I obviously didn't want to evaluate: directly querying the AssetWriteDb from the Contract Microservice

NOTE: there is a "public" api gateway that "protects" all internal microservices from the external. the api gataway is exposing always right queries needed for clients that are querying mongodb in the right way. this question is just about internal processing of the aggregates and how to "query" Write Models between microservices

NOTE 2: I didn't write the "synchronization" business logic (the RefreshContractAggreagteHandler) because it's simply a "sql query" to the ContractWriteDb projecting a "ContractAggregate", then to map the assetCount I have the same issue, I want to query the AssetWriteDb from the Contract Microservice, so there is exactly the same of the main question)

Answer 1

Remember that there can be arbitrarily many read models, optimized for the particular query/queries. Assuming that the changes to the contract ID in the asset microservice are captured in an AssetChangedEvent, then your contract service can maintain its own mapping of assets to contract IDs as part of its write model and then when you need to resolve the contract ID for a given asset, you check that mapping. Even though that mapping is concretely part of the contract write model (it might be a table in the contract mssql), conceptually it's a read model for assets (in fact the stream of AssetChangedEvents is a read model for assets, which means the event handler already has at least a toe in the asset read model pool as well as in the contract write model pool).

The AssetChangedEvent handler then checks first to see if the event is touching the contract ID; if so, it updates the mapping.

As an aside, it looks like this microservice decomposition was based on taking the tables from a relational schema and making each table its own microservice. This is one of the expressways to a lot of extra complexity (especially if you want synchronization). It's generally a better idea (though one that nearly every practitioner has to learn "the hard way") to decompose based on the commands. If assets and contracts are so tied together that changes to one tend to ripple into changes to the other (especially if stronger consistency guarantees are required), then having them in the same microservice might be the best idea.