Great tutorials really helped me with work. Your soft tone along and clear explanations helps me understand. Thank you so much, really appreciated!! Looking forward to future videos.
Great video, one question here what if I have different databases also for order and inventory service as you are deleting the order from inventory service? In that case how my orders will be deleted??
@@DotNetCoreCentral Yes but how? As inventory service won't have access to order database then how inventory service will delete order details?? Or inventory service will call backwards to order service with different endpoint for deletion request how this will communicate for each other??
Nice tutorial, however I am wondering that as per the microservice approach, we should not update more than one table from one microservice, this is confusing me why transaction is applied within one microservice?
The main idea behind the Choreography pattern is to have a service choreograph the distributed transaction. The service from where the choreography happens can be a dedicated service just to do that. It is up to you how you want to choreograph the transaction.
Great Video. It really helped me a lot to understand microservices. But why didnt use event bus instead of hostedservice? is there any pros and cons use event bus?
@Antonius Bayu, thanks for watching! You will use an event bus when you are building reactive microservices, and this is something I have shown in a few of my videos. You will use REST services where you need to respond to client calls, e.g., from a web UI or an external integration. There is a use case for both, it really depends on the business requirement.
Hey Nirjhar, I like your videos they allow me to learn quickly. I know the code in the video is only an example but in a production environment, the orderDeletor.Delete compensating call in InventoryResponseListener.Subscribe method could itself fail which would leave the data in an inconsistent state. Thus, compensating actions could benefit from retry mechanisms to make the overall system more robust. Is this a reasonable thought or is there some other mechanism that would deal with this? I see the choreography implementation quickly becoming complex to cover failures of compensating actions, and I am not a fan of the single point of failure that comes with an orchestration implementation unless the orchestrator itself could be clustered and the state managed across its replicas. What are your thoughts on additionally making an application able to tolerate and accept inconsistent data and recognize incomplete data as being part of failed or uncompleted operations and deal with them accordingly providing it is in line with business requirements? Obviously it would not be good for inventory counts to get out of whack with real stock levels so for that business requirement retries all the way even on the compensating actions until they themselves succeed within a choreography implementation.
@Emmanuel Mouille, thanks for watching the video and taking the time to provide your valuable comment. And you are absolutely right, compensating operations should have retries through something like Polly implemented, which can me things complex and cumbersome. But to build a highly scalable and consistent system it's a smaller price to pay in my opinion. And your point about orchestration is also valid, and that is the reason we tend to avoid it for transactions where we are dealing with a few microservices. But what I have seen in my experience, orchestration implementation provides self-documentation about the distributed transaction, which is missing in choreography. In the case of choreography, we end up maintaining documentation in architecture documents which easily becomes stale. Regarding applications to deal with incomplete data due to the previously failed transactions might get very subjective but it is definitely doable with an external poison data queue and managing another distributed database for all the failed transactions. I am just thinking out loud, we can definitely come up with an architecture, but it is going to be complex :)
@@DotNetCoreCentral What I take from that is that there is not one single solution that fits all scenarios. For some scenarios, the application can totally deal with data inconsistency or eventual consistency. For other scenarios, the data must be consistent and there are multiple approaches such as sagas like you describe here, or event sourcing as a single source of truth to enact necessary compensations or reconciliations. Consideration of domain boundaries and application design could also help reduce the effort made for achieving data consistency where required. For example if there are a lot of cross cutting concerns between two services and it might be simpler to have a single database store that serves them both (Shared database pattern vs Database per service pattern). Taking a hybrid approach could be the way to reduce complexity as this is the major point of contention with achieving data consistency in a microservice architecture. I'm going to watch more videos on data consistency in microservices all look at an array of solutions so that I can apply any of them where best fitted within a single product.
@@emmanuelmouille5480 yes, there is no one size fits all solution. It depends on business needs and also the organization. But data consistency is a huge topic, I have done my share of work on breaking monoliths to microservices, in some cases I could get into one db per microservice and maintain distributed transaction. In certain cases, I kept a single DB across services. A lot of factors goes into deciding an ideal solution, at the end of the day the important thing is to meet the business need, rather than fitting architecture into a business problem :)
But u r calling orderdeleter as a service with a blocking call right? Thats not choreo I guess. It should be fire and forget. So just publish another message that ordertodelete. That message needs to be subscribed again
@Rambo, yes correct, but for simplicity of the example I made that blocking call, but as you can see rest of the other transactions were all through asynchronous messages.
Good Content
Great tutorials really helped me with work. Your soft tone along and clear explanations helps me understand. Thank you so much, really appreciated!! Looking forward to future videos.
@Anthony Fa, thanks so much for watching the video, I am glad my tutorial could help you.
Very depth and easy understandable content. Thank you so much
Thanks for watching!
very well explained !!! Thanks
@rajiv gopale, thanks for watching!
Thanks I learned something but how does the data like success or error response is sent back to the client app ?
top quality content, thanks
@SirGottfried, thanks for watching!
Great content, thanks for that! I have a question: Why initialize these services in singleton? Maybe should i use scoped lifetime?
Why have you not used mass transit ?
Parabéns! Mt bem explicado, por mais vídeos assim.
@Ricardo Bastos, thanks for watching!
Thank you , Clean code and nicely explained.
@Antariksh verma, thanks!
Good job. Thanks
@Mahendran Chinnaiah, thanks for watching!
Thank you for the nice video, could you please do a demonstration for saga orchestration as well
@vinod abraham, thanks for watching! I will definitely do it.
For SAGA there will be SagaDBcontext and statemachine kind of architecture , but what you are teaching is not the SAGA
Great video, one question here what if I have different databases also for order and inventory service as you are deleting the order from inventory service? In that case how my orders will be deleted??
@UglyMOON, in that case, the order needs to be deleted, yes. And that needs to be managed by the Saga
@@DotNetCoreCentral Yes but how? As inventory service won't have access to order database then how inventory service will delete order details?? Or inventory service will call backwards to order service with different endpoint for deletion request how this will communicate for each other??
Nice tutorial, however I am wondering that as per the microservice approach, we should not update more than one table from one microservice, this is confusing me why transaction is applied within one microservice?
The main idea behind the Choreography pattern is to have a service choreograph the distributed transaction. The service from where the choreography happens can be a dedicated service just to do that. It is up to you how you want to choreograph the transaction.
Great Video. It really helped me a lot to understand microservices. But why didnt use event bus instead of hostedservice? is there any pros and cons use event bus?
@Antonius Bayu, thanks for watching!
You will use an event bus when you are building reactive microservices, and this is something I have shown in a few of my videos.
You will use REST services where you need to respond to client calls, e.g., from a web UI or an external integration.
There is a use case for both, it really depends on the business requirement.
Hey Nirjhar,
I like your videos they allow me to learn quickly.
I know the code in the video is only an example but in a production environment, the orderDeletor.Delete compensating call in InventoryResponseListener.Subscribe method could itself fail which would leave the data in an inconsistent state. Thus, compensating actions could benefit from retry mechanisms to make the overall system more robust. Is this a reasonable thought or is there some other mechanism that would deal with this?
I see the choreography implementation quickly becoming complex to cover failures of compensating actions, and I am not a fan of the single point of failure that comes with an orchestration implementation unless the orchestrator itself could be clustered and the state managed across its replicas.
What are your thoughts on additionally making an application able to tolerate and accept inconsistent data and recognize incomplete data as being part of failed or uncompleted operations and deal with them accordingly providing it is in line with business requirements? Obviously it would not be good for inventory counts to get out of whack with real stock levels so for that business requirement retries all the way even on the compensating actions until they themselves succeed within a choreography implementation.
@Emmanuel Mouille, thanks for watching the video and taking the time to provide your valuable comment.
And you are absolutely right, compensating operations should have retries through something like Polly implemented, which can me things complex and cumbersome. But to build a highly scalable and consistent system it's a smaller price to pay in my opinion.
And your point about orchestration is also valid, and that is the reason we tend to avoid it for transactions where we are dealing with a few microservices. But what I have seen in my experience, orchestration implementation provides self-documentation about the distributed transaction, which is missing in choreography. In the case of choreography, we end up maintaining documentation in architecture documents which easily becomes stale.
Regarding applications to deal with incomplete data due to the previously failed transactions might get very subjective but it is definitely doable with an external poison data queue and managing another distributed database for all the failed transactions. I am just thinking out loud, we can definitely come up with an architecture, but it is going to be complex :)
@@DotNetCoreCentral What I take from that is that there is not one single solution that fits all scenarios. For some scenarios, the application can totally deal with data inconsistency or eventual consistency. For other scenarios, the data must be consistent and there are multiple approaches such as sagas like you describe here, or event sourcing as a single source of truth to enact necessary compensations or reconciliations. Consideration of domain boundaries and application design could also help reduce the effort made for achieving data consistency where required. For example if there are a lot of cross cutting concerns between two services and it might be simpler to have a single database store that serves them both (Shared database pattern vs Database per service pattern). Taking a hybrid approach could be the way to reduce complexity as this is the major point of contention with achieving data consistency in a microservice architecture. I'm going to watch more videos on data consistency in microservices all look at an array of solutions so that I can apply any of them where best fitted within a single product.
@@emmanuelmouille5480 yes, there is no one size fits all solution. It depends on business needs and also the organization. But data consistency is a huge topic, I have done my share of work on breaking monoliths to microservices, in some cases I could get into one db per microservice and maintain distributed transaction. In certain cases, I kept a single DB across services. A lot of factors goes into deciding an ideal solution, at the end of the day the important thing is to meet the business need, rather than fitting architecture into a business problem :)
But u r calling orderdeleter as a service with a blocking call right? Thats not choreo I guess. It should be fire and forget. So just publish another message that ordertodelete. That message needs to be subscribed again
@Rambo, yes correct, but for simplicity of the example I made that blocking call, but as you can see rest of the other transactions were all through asynchronous messages.