FREE Training Session:

Microservice Data Consistency Pitfalls


Trying to say "no" to distributed transactions? Watch this to learn about the distributed transactions you did not know you were doing: learn some mistakes you did not know you were making, and that are mostly ignored by the complex patterns out there - like Sagas or eventual consistency.

The Hidden Pitfalls of your Microservice Architecture

Even if you don't realise it, your microservices are most likely doing some form of distributed transactions. Here we give 5 typical examples of distributed transactions based on our 20+ years of experience in distributed computing, and the pitfalls if you fail to recognise them. For detailed illustrations, please watch the video above...

1. The Synchronous Network Call

The simplest case of a distributed transaction: this happens if you are calling a remote service via the network and you get a network timeout. It is impossible to say whether you actually made some remote changes, or not.

2. The Message Sender

This is when your microservice updates its database and also sends out a notification message about the change. The typical implementation has one of these three problems in the presence of crashes or exceptions:

  1. Lost messages: the database was updated, but no message sent.
  2. Duplicate messages: the message was sent several times.
  3. Ghost messages (that should not even exist) because there is no DB corresponding DB change.

3. The Message Receiver

This is when your microservice processes incoming messages and updates its database. The typical implementation has one of these problems:

  1. Message loss: the message is not processed but rather deleted.
  2. Duplicate message processing: the message is processed twice or more.

4. The Cache

A microservice that uses a cache is also doing distributed transactions: it needs to maintain the cache in-sync with the DBMS and the other way around. The typical implementation can suffer from a stale cache, leading to data corruption.

5. The Backups

When two microservices require consistent data, their databases can go out-of-sync if one of them crashes and is recovered from an old backup image.

What About... Eventual Consistency?

This is a very complex coding solution that is also very error-prone and expensive to maintain (see the video above for details). We have something better, as explained in the course you can register for on this page!

What About... Sagas?

Again, this is complex: most people we have talked do did not want to do this because of the cost and complexity of the undo logic. We have something better, as explained in the course you can register for on this page!

Introducing: "Microservice Transaction Patterns"

Our full online course gives you additional details about each of the examples above, along with our unique and easy solutions so you don't suffer any of the risks. As a thank you note for visiting us today, we can offer a time-limited 80% OFF the regular price!

CHECKOUT OUR FULL ONLINE COURSE VIA THE BUTTON BELOW AND CLAIM YOUR 80% OFF TODAY:

DISCOUNT VALID FOR A FEW DAYS ONLY!

If you're interested in learning more then make sure to act FAST: our discount is valid for a few days only.