Microservices has become popular in recent years as a way to structure an application. But are you doing it right? 

As a software development company that has successfully executed various projects involving microservices, we have compiled this blog to discuss some of the considerations you need to make when implementing it, including transactions and dual writes. 

Microservices Primer

Microservices is a way of structuring an application as a set of small, independent services. Each service has its database and runs in its own process. 

The business benefits of this approach include improved modularity, easier scaling, and simpler deployments. These benefits have led to a widespread acceptance of microservices among IT (Information Technology) executives and application development professionals. According to a recent study conducted by IBM, the most common microservices use cases include data analytics/business intelligence, database applications, customer relationship management, customer transactions/commerce/customer service, finance, and human resource applications.

Information source: IBM.com

However, the study also found that some challenges come with microservices. These include:

• There’s a lot of room for complexity to arise.
• Many software development companies struggle with a lack of in-house expertise with microservices.
• Contention surrounds which applications to migrate, data security, and the necessary timeframes and expenses involved in adopting a long-term microservices strategy.

Microservices Problem Areas and Solutions

As noted above, one of the main problems with microservices is that it can introduce complexity. For example, when multiple services are running in different processes, coordinating them can be difficult. 

Transactions

Transactions are a way of ensuring that two or more operations are done together. This way, if one operation fails, you can roll back the other.

In a microservices architecture, each service has its own database. Therefore, if you want to do a transaction that spans multiple services, you need to use a distributed transaction manager.

A distributed transaction management (DTM) system coordinates transactions that span multiple databases and ensures that all the changes are either committed or rolled back together.

There are a few different ways to do this, but a two-phase commit (XA) is the most common. In XA, each service involved in the transaction first prepares its database. Once all the services have prepared their databases, the DTM system commits all the changes. If any of the services fail to prepare their database, the DTM system rolls back all the changes.

Dual Writes

Another problem with microservices is that each service has its own database. This can lead to inconsistencies if two services try to update the same data. For example, imagine you have a customer service application and an order management application. Both applications have their own database.

If a customer calls to change their address, the customer service application will update the address in its database. But the order management application will still have the old address. This can lead to orders being sent to the wrong address.

Dual writes is a technique where each service writes to its own database. This can cause data inconsistencies. The solution is to ensure that the service also writes to a central “master” database. The other services can then read from the master database.

This way, if one service updates the data, the other services will see the change right away. And if one service goes down, the others can still work with the data in the master database.

Another solution would be to avoid dual writes in event-driven architectures altogether.

As one of the leading software development companies in Ohio, our team at Expeed has years of experience with microservices. We can help you avoid the pitfalls and get the most out of this robust architecture. Contact us today to learn more.