search

dotnet-architecture / eShopOnContainers

Cross-platform .NET sample microservices and container based application that runs on Linux Windows and macOS. Powered by .NET 7, Docker Containers and Azure Kubernetes Services. Supports Visual Studio, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other code editor. Moved to https://github.com/dotnet/eShop.
https://dot.net/architecture
24.54k stars 10.36k forks source link

Possible inconsistency when publishing intergration events failed #174

Closed FDUdannychen closed 7 years ago

FDUdannychen commented 7 years ago

From the code I think it's possible to generate inconsistent data when the event and context(e.g. OrderingContext) is successfully saved, but failed to publish. For example, in UpdateOrderWhenBuyerAndPaymentMethodVerifiedDomainEventHandler, _orderingIntegrationEventService.SaveEventAndOrderingContextChangesAsync succeeds, while _orderingIntegrationEventService.PublishThroughEventBusAsync fails.

I think the events need to be re-published in some way? Or I'm missing something?

CESARDELATORRE commented 7 years ago

@FDUdannychen So, when publishing through the Event Bus, just in case there could be any error when publishing the message through RabbitMQ, we're making sure that we are persisting the event in an Integration Events Log table so each event is marked as successfully sent or not. This "achieving atomicity" approach is described in the Guide/eBook. Then, additional code/artifacts could be implemented (like a worker process or background task) looking for events in that EventLog table that were not successfully sent through the event bus and they could be re-sent. However, for simplicity's sake in the sample app, we're not implementing that additional level (re-publishing action). More importantly, take into account that the Event Bus implementation that we made over RabbitMQ should be considered as a simple PoC (Proof of Concept) to be used just during an evaluation process of the eventual consistency between microservices based on an Event Bus. But for a real/production application, we don't recommend that implementation as it doesn't cover all the needs (and this is explicitly said in the Guide/eBook) and you should use a production-ready Service Bus (like NServiceBus, MassTransit, Brighter, etc.) which offer and end-to-end solution for resiliency plus many more features like "inbox/outbox pattern", message routing, message de-duplication, complete Saga framework support, etc. Azure Service Bus could also be a possibility for your Event Bus implementation, however it is in a lower level (kind of transport level) than the other mentioned Service Buses and doesn't offer all the those frameworks at the application level and resiliency mechanisms like atomicity, Sagas, etc. In fact, all of those higher level Service Buses can work on top of Azure Service Bus so they take advantage of Azure Service Bus scalability in Azure's cloud. Hope this helps.

ffrankozz commented 2 years ago

Hi, In the above method, I do not see any code either saving the event to db nor the event being published. What am I missing?