This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 67%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
In a hospital management system built with micro services using .NET Core and Entity Framework, how can we ensure data consistency when generating Medical Record Numbers (MRNs)? Since MRNs cannot be deleted, how can we handle situations where a downstream service failure occurs after MRN generation using the Saga pattern with compensating transactions?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 61%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
you have two options:
Thanks for your quick response. Since MRNs need to be generated and persisted for subsequent microservice processing, the second option (assign the MRN as the last step of the saga) is not viable. In compensating transactions, can we use rollback like normal transactions, or should we use another mechanism rather than the compensation pattern?
a compensating transaction is used to do a rollback. a typical approach would be each micro service supports rollback/undo message. the compensating transaction is like a new saga, that calls each micro service to do an undo. you will have to write the undo code.
https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
another option is the orchestrator saves state at the beginning of the saga and can restore state independent of the Micro services. this can be difficult if two concurrent sagas change the same data.
if you are going to the saga pattern you should design you update transactions carefully and they should be idempotent (repeatable) and support undo. designing the undo is as important as the update.
Thanks for your response. Designing the undo operations is as important as the updates. In compensating transactions, we cannot use rollback like normal transactions. Instead, we need to implement a compensating action to revert the system to its previous state. Could you provide guidance on how to implement this effectively in our context?