This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Transaction management in microservices

 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This may be a repetitive question, but I was unable to find a satisfying answer.
Let me say there are two microservices:
1. order microservice
2. inventory microservice
Let me say that there is a payment api which processes the payments
If a request is placed for an order, the payment gets connected by the order service and finally the inventory is also updated accordingly.
How do we manage the transactions in this scenario???
Also if there is only one item in the inventory with more than 10 requests coming up for that single item at the same time, which one do we process for that single item and how do we handle the other requests???
Please suggest!
Thanks!
 
Bartender
Posts: 1164
38
IBM DB2 Netbeans IDE Spring Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally speaking, when dealing with microservices you have to give up with the 'classical' concept of (global) transaction in favour of eventual consistency.
I suggest you to read Martin Fowler's article about microservices trade-offs.
In a nutshell, when using a monolithic architecture, is more or less easy to wrap all services operations in a single, distributed transaction which of course can only be commited or rolledback.
One of microservices' cornerstone is that each microservice is responsible only for its own managed data - data that may reside on different database - with no global transaction manager that can help you in avoiding inconsistencies.

You need to design carefully your application to manage consistency "manually". In the example you posted, for example, you may want to only "reserve" items in your inventory / warehouse when an order is made by a customer.
Required goods are marked as "reserved" and only when the payment is fulfilled, you can mark them as "sold".
 
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Claude Moore wrote:You need to design carefully your application to manage consistency "manually". In the example you posted, for example, you may want to only "reserve" items in your inventory / warehouse when an order is made by a customer.
Required goods are marked as "reserved" and only when the payment is fulfilled, you can mark them as "sold".



This is more or less exactly what our system did at the wholesale distributor I used to work at. Except that "reserved" and "on hand" were reduced at shipping time, not at payment time. We didn't do that because of possible transaction issues, but because it's a better design. In fact we didn't use transactions at all and this design never caused a problem which could have been fixed by using a transaction.

Of course it helped that all of the tables involved were in the same database.

I haven't read what Fowler has to say but it's true that it's possible to manage updates to different databases via distributed transactions. Possible, but not easy I think.
 
Sriram Sharma
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear friends,
Thanks for the suggestions.

Paul,
So you had only one database for all services. Is it?

Others,
your suggestions and references are always welcome.

Thanks!
 
Paul Clapham
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Sriram Sharma wrote:Paul,
So you had only one database for all services. Is it?



Services? There was no such thing in those days. My feeling is that the only way to manage consistency via design is to design the system so that database updates don't fail. Which is more difficult if you've got a system which is scattered all over the place.
 
Saloon Keeper
Posts: 5708
144
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're concerned with consistency in the absence of DB transactions and rollbacks, you should look into the concept of compensating actions or compensating transactions. Basically, it means keeping track of what needs to be undone if something goes wrong at any particular point. See https://docs.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction. A "transaction" in this context does not have to be a transaction in the DB sense of the word.
 
Claude Moore
Bartender
Posts: 1164
38
IBM DB2 Netbeans IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Sriram Sharma wrote:
Paul,
So you had only one database for all services. Is it?



I think to understand what you're asking between the lines: if each  microservice should use its own database.
Well, in theory each microservice should be completely isolated from other microservices, of course except for the API it exposes. In this sense, use separated database make perfectly sense.
But in practice I could not say if it's always a good idea. For example, let's suppose that in the scenario you described a microservice A is responsible for registering orders, and calls microservice B to book goods in the warehouse.
Internal representation of "inventory item" could be in theory very different for each microservice. And that's right, because in theory you could replace microservice B with something else. But what happens when you need to create some report
which needs to join orders and inventory data, for example how many goods have been shipped last month , to fullfill which orders ? At the very end, you may want to build a report service that directly accesses to both databases managed by A and B, or, otherwise,
you need to manually get orders data from A, inventory data from B and manually put them together. I don't think that's an handy process....
In my humble opinion, it's better if the database is the same, and to impose some strict rule to prevent services to by-pass each other, by accessing directly tables they are not responsible to manage.


 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

look i am not an expert about micorservices but i have been reading i think some thing like kafka might come into play in your situation ,using kafka ability to talk to databases and communicate with micriservices produces can help you get rid of some of the communication problems that you might be facing right now
 
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Sriram Sharma wrote:
How do we manage the transactions in this scenario???



You can learn from Amazon a bit ))

Imagine you order a few books on Amazon. When you ordered it --- the following things happens (simplified):

1. You get an email "Thank you for shopping with us. You ordered a few books". This is just a confirmation. Amazon got your order
2. A few hours later you get a message from your bank -- your credit card is charged
3. Next day you get an email "Your Amazon.com order has shipped..."

You see - it is not one single transaction. There are hours or days between (1) (2) and (3)

And sometimes... there are problems in the system:
After (1) --a few hours or days later-- you get a message saying "Oops! One of the books you ordered is out of stock. Sorry. We ship you (and charge your credit card) just 2 other books"
This is a compensating transaction in action

I hope you got the idea )
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!