Microservices architecture and distributed transaction
up vote
2
down vote
favorite
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it. Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api) and it has no knowledge about distributed transaction it rises some issues you have to deal with when something goes wrong: suppose u have microservice "make payment for item". When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work. If every part of this sequence succeded everything is good but the question is how to deal with errors, another api you are calling is unavailable, but your have changed state in many other systems, how to recover from there? is there some good approch to such situations?
microservices
asked Nov 10 at 21:14
Macko
13119
add a comment |
up vote
2
down vote
favorite
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it. Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api) and it has no knowledge about distributed transaction it rises some issues you have to deal with when something goes wrong: suppose u have microservice "make payment for item". When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work. If every part of this sequence succeded everything is good but the question is how to deal with errors, another api you are calling is unavailable, but your have changed state in many other systems, how to recover from there? is there some good approch to such situations?
microservices
asked Nov 10 at 21:14
Macko
13119
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it. Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api) and it has no knowledge about distributed transaction it rises some issues you have to deal with when something goes wrong: suppose u have microservice "make payment for item". When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work. If every part of this sequence succeded everything is good but the question is how to deal with errors, another api you are calling is unavailable, but your have changed state in many other systems, how to recover from there? is there some good approch to such situations?
microservices
asked Nov 10 at 21:14
Macko
13119
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it. Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api) and it has no knowledge about distributed transaction it rises some issues you have to deal with when something goes wrong: suppose u have microservice "make payment for item". When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work. If every part of this sequence succeded everything is good but the question is how to deal with errors, another api you are calling is unavailable, but your have changed state in many other systems, how to recover from there? is there some good approch to such situations?
microservices
microservices
asked Nov 10 at 21:14
Macko
13119
asked Nov 10 at 21:14
Macko
13119
edited Nov 10 at 21:34
asked Nov 10 at 21:14
Macko
13119
asked Nov 10 at 21:14
Macko
13119
asked Nov 10 at 21:14
Macko
13119
13119
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
answered Nov 10 at 21:35
muradm
732419
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting thatto be sure everything endedis requirement, how yourmicroservicecan make sure that everything is ended. Microservice is responsible for someBounded Context, for single type of task. Otherwise it seems to be not microservice if it knowseverything. It is eitherdistributed monolithorSaga, choose one. The point ofmicroservicesis to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.
– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have likemicroservice to send email notification,microservice to create customer,microservice to put orderetc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiatingcommandsand polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.
– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
answered Nov 10 at 21:35
muradm
732419
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting thatto be sure everything endedis requirement, how yourmicroservicecan make sure that everything is ended. Microservice is responsible for someBounded Context, for single type of task. Otherwise it seems to be not microservice if it knowseverything. It is eitherdistributed monolithorSaga, choose one. The point ofmicroservicesis to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.
– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have likemicroservice to send email notification,microservice to create customer,microservice to put orderetc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiatingcommandsand polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.
– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
add a comment |
up vote
2
down vote
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
answered Nov 10 at 21:35
muradm
732419
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting thatto be sure everything endedis requirement, how yourmicroservicecan make sure that everything is ended. Microservice is responsible for someBounded Context, for single type of task. Otherwise it seems to be not microservice if it knowseverything. It is eitherdistributed monolithorSaga, choose one. The point ofmicroservicesis to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.
– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have likemicroservice to send email notification,microservice to create customer,microservice to put orderetc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiatingcommandsand polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.
– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
add a comment |
up vote
2
down vote
up vote
2
down vote
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
answered Nov 10 at 21:35
muradm
732419
There is no right or wrong question actually. But here is my point of view.
Let's break it down:
microservices are present some time ago, there are pros and cons of this approach but one of the points u will eventually have to face with is transaction atomicity or rather not having it
Exactly, normally, you are to avoid having distributed transactions, that is one of important points.
Enterprise apps usually have some kind of Unit Of Work on api level but in environment where your microservice is calling another microservice (or api)
Normally, you don't call another microservice, otherwise it turns to become distributed monolith where all your so called microservices depend on each other as if they would be in single executable. When talking about microservices, it is all about to make them as independent as possible. This can be achieved with various techniques, one of which is Event Sourcing for example. Where you define your events and microservices processing them.
When client calls your microservice api this method internally: place some data in owned database, create invoice file, sends it to another microservice, send email, maybe call another system which knows nothing about your unit of work.
In terms of Event Sourcing here you are talking about Sagas. The processes that orchestrate the work done.
but your have changed state in many other systems, how to recover from there
This is design issues, as pointed before, having microservices forming distributed monolith is not actually microservices.
In general, microservice is not just a separated executable. It is design practice. Where you are designing your system in the way, such kind of questions are not happening. I would suggest reading authors on DDD (Domain Driven Design), Event Sourcing, CQRS, Bounded Context etc. This probably will make things more clear to you. Like Martin Fowler, Greg Young. Will try adding names here is it will come to my mind.
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
answered Nov 10 at 21:35
muradm
732419
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
edited Nov 10 at 21:38
Sergio Tulentsev
177k29286301
177k29286301
answered Nov 10 at 21:35
muradm
732419
answered Nov 10 at 21:35
muradm
732419
answered Nov 10 at 21:35
muradm
732419
732419
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting thatto be sure everything endedis requirement, how yourmicroservicecan make sure that everything is ended. Microservice is responsible for someBounded Context, for single type of task. Otherwise it seems to be not microservice if it knowseverything. It is eitherdistributed monolithorSaga, choose one. The point ofmicroservicesis to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.
– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have likemicroservice to send email notification,microservice to create customer,microservice to put orderetc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiatingcommandsand polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.
– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
add a comment |
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting thatto be sure everything endedis requirement, how yourmicroservicecan make sure that everything is ended. Microservice is responsible for someBounded Context, for single type of task. Otherwise it seems to be not microservice if it knowseverything. It is eitherdistributed monolithorSaga, choose one. The point ofmicroservicesis to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.
– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have likemicroservice to send email notification,microservice to create customer,microservice to put orderetc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiatingcommandsand polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.
– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
mentioned flow of calls is only simple case and calling other apis from microservice is rather standard way of doing things synchronously. Requirement is that call to my microservice has to return execution result right now so before returning info to client i have to be sure everything ended with success including resolving errors in comunication to other apis which mostly can't be changed to my needs.
– Macko
Nov 10 at 22:02
That is the point. If you are putting that
to be sure everything ended is requirement, how your microservice can make sure that everything is ended. Microservice is responsible for some Bounded Context, for single type of task. Otherwise it seems to be not microservice if it knows everything. It is either distributed monolith or Saga, choose one. The point of microservices is to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.– muradm
Nov 10 at 22:11
That is the point. If you are putting that
to be sure everything ended is requirement, how your microservice can make sure that everything is ended. Microservice is responsible for some Bounded Context, for single type of task. Otherwise it seems to be not microservice if it knows everything. It is either distributed monolith or Saga, choose one. The point of microservices is to split your architecture in the way that you have identified boundaries and responsible microservices, then you need to either orchestrate them, or design your front facing API accordingly.– muradm
Nov 10 at 22:11
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
still not clear: so my microservice should only response to client "work has been initiated with success"? what if client want to have result of entire work to check if work is done - has to subscribe to bus or use polling?
– Macko
Nov 10 at 22:16
Not necessarily. That depends on your design. You will have like
microservice to send email notification, microservice to create customer, microservice to put order etc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiating commands and polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.– muradm
Nov 10 at 22:22
Not necessarily. That depends on your design. You will have like
microservice to send email notification, microservice to create customer, microservice to put order etc. Each of them is responsible for a some clearly bounded context. Then how you initiate them, also depends. For instance look at this: microservices.io/patterns/data/saga.html. If you are ok with initiating commands and polling result, that is one way. If you require to "block", you can make kinda of wrapping process or saga, that will keep track of execution. That all depends on context, domain and requirements.– muradm
Nov 10 at 22:22
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
ok, so this is my requirement: microservice should respond in sync pattern to client. How to do this to be ok with microservice architecture?
– Macko
Nov 11 at 17:33
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53243468%2fmicroservices-architecture-and-distributed-transaction%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
