Data Models Challenges in Microservices architecture

One of the primary benefit of the microservices model is its ability to organize development teams according to bounded contexts(sub-models).

In monolithic applications, shared database creates high coupling between different domains, if data is wrongly architected, it will be highly coupled, which may require downtime to upgrade.

While Monolithic application depends on on ACID principles to resolve consistency issues, Microservice approach is 'Share-Nothing', which may lead to de-normalized data models that cause duplicates and inconsistency.

There are different approaches, can be briefly determined as following:

1. Database Per service: Service can't access data models out of its domain responsibility

Pros: Loosely couples

Cons: Not straight forward, complicated.

2. Shared Database: 

Pros: Straight forward, ability to apply ACID principles 

Cons:  Coupling between data models, And We can reply that EDA can be applied at the level of database, and decrease coupling using it

3. API composition: Check for data from the other services

Pros: Direct

Cons: Additional complexity, Service coupling, which is against microservice architecture.

4. CQRS & Event Sourcing: Which you should notify the object changes due to the CQRS pattern, and to notify listeners by changes using the EDA, which guarantee 'At least once' publishing to interested services

Pros: Support the integrity by adding database objects (Views, Functions, Procedures) with defined responsibility.

Cons: Complexity, and code duplicates

5. SAGA: relies on orchestrating a sequence of local transactions, which is responsible for building local transactions, but the revert of the transactions in case of failure will.

Pros: Good for services provided by different solution providers

Cons: Higher complexity

6. Database type: relational/non-relational

Since micro-services architecture is moving to largescale solutions, you should move forward to:

• Normalized database: in order to meet relationships and enable reporting

• DE-normalized database, as a normalized database impacts the database performance dramatically, due to the referential integrity constraints.

• Non-relational database: Which enables scalability for the database, vertically and horizontally, without performance overheads.

Finally,

As and Architect, you are responsible about data integrity, using different technology domains(Microservice/relational databases/non-relational databases/AI, etc.), that direct you according to each context (Single/Multiple service provider) to implement the best fit approach to achieve the objective with minimal overheads and drawbacks.

This may be challenging, to have fully independent domains, that destroy relationships between objects, accept inconsistencies, require building healthy checkers to resolve it.

In addition, you should think about evaluating any approach, not only micro-service architecture, rather than applying everything, without considering the architecture trade-offs like:

• Complexity

• Consistency

• Fit for purpose

• Fit for use