Data Consistency

Since microservices are autonomous, they will usually have to keep a copy of the data they need to perform its business logic in their own database.

Usually when we think about this, we think it's a bad idea. Like, why would you duplicate information? Just share the database! it's all there. But going down that road, you will quickly realize that's a terrible idea! One service making a change in the DB schema will break all others.

Instead, each service has it's own DB. They embrace DDD, particularly the ubiquitous languages, meaning that, each service will have it's own domain entity with the fields it require to perform its business logic.

Note

The only exception to this no-database sharing rule is for Services within the same Bounded Context.

That entity will be correlated to the source of truth, meaning the service that "owns" the entity, by using a Correlation ID.

Note

The Correlation ID, is the ID of an entity in a distributed system. It is "correlated" in different services using that unique identifier.

Whenever the source of truth updates the entity, events are fired for subscribers to keep up to date. Services that are keeping a copy of another service's entity, will subscribe to its events in order to keep its database updated.

Many times you will want to add custom fields to the entity you are mirroring. That is where DDD comes handy, in your mirrored copy you can add whatever fields you see fit. You'd then expose a events for modifying those fields and would call them inside your application or from the AdminCenter.

Eventual Consistency

Whenever we have data redundancy, we will have constraints about consistency. The Suite 3.0 has eventual consistency: when a change is made in a service it will be eventually reflected in other services.

Autonomy has a cost, as usual it is a tradeoff.

Failure is a tradeoff

We can decide if our service can afford to fail or not, we design for failure.

For example, the Admin Center can afford to stop the creation/edition of Users if the Users Profile service is currently down.

This is an acceptable tradeoff in the Admin Center's domain. For an application like AIMS/iInspector, they cannot afford to go down when the Users Profile Service or other backend service is down. They will want to keep autonomy as much as possible, hence they will want to mirror as many data as they require to execute their business logic.