Challenges in Microservices

Data Access:

Data access becomes much more complex when you move to a microservices architecture. Because in microservices we encapsulate the data to ensures that the microservices are loosely coupled and can evolve independently of one another. The data owned by each microservice is private to that microservice and can only be accessed via its microservice API.

Challenges are :

• If multiple services were accessing the same data, schema updates would require coordinated updates to all the services. This would break the microservice lifecycle autonomy
• You can't make a single ACID transaction across microservices because it means that we must use eventual consistency when a business process spans multiple microservices. This is much harder to implement than simple SQL joins, because you can't create integrity constraints or use distributed transactions between separate databases.
• Different microservices often use different kinds of databases. How do we deal with that?

Boundaries:

How to define the boundaries of each microservice?

We know that we have to define multiple fine grained services but how do we define responsibilities of each service? How do we know their logical boundaries?

For Solution refer to: Identifying Boundaries

Retrieve data between multiple microservices:

How to create queries that retrieve data from several microservices?

Challenging part is we want to avoid chatty communication to the microservices from remote client apps. And not only that, we want to improve the efficiency in the communications of your system.

Solutions are:

• API Gateway: This is a service that provides a single-entry point for certain groups of microservices. It's similar to the Facade pattern from object-oriented design, but in this case, it's part of a distributed system.
• CQRS with query/reads tables: aggregating data from multiple microservices is the Materialized View pattern. In this approach, you generate, in advance (prepare denormalized data before the actual queries happen), a read-only table with the data that's owned by multiple microservices. The table has a format suited to the client app's needs.
• "Cold data" in central databases

Consistency across multiple microservices

How to achieve consistency across multiple microservices?

Challenge is the data owned by each microservice is private to that microservice and can only be accessed using its microservice API. Therefore, a challenge presented is how to implement end-to-end business processes while keeping consistency across multiple microservices?

A good solution for this problem is to use eventual consistency between microservices articulated through event-driven communication and a publish-and-subscribe system.

Communication across microservice

How to design communication across microservice boundaries?

In a distributed system like a microservices-based application, with so many artifacts moving around and with distributed services across many servers or hosts, components will eventually fail. Partial failure and even larger outages will occur, so you need to design your microservices and the communication across them considering the common risks in this type of distributed system.

Solution can be found at: Communication in Microservices