التعامل مع التعويض باستخدام الأحداث

In choreography sagas, services react to events. But what happens when one of those services fails to complete its part of a distributed transaction?

We need a way to undo any actions that were successfully performed by previous services. This is where compensation comes in.

Compensation is the process of reversing previously completed operations within a distributed transaction. Think of it as a 'rollback' mechanism tailored for microservices.

It ensures that if any step in a multi-service business process fails, the system can return to a consistent state.

In a choreography saga, there's no central orchestrator. Services communicate directly via events. So, how do we trigger compensation?

• When a service fails to complete its task, it publishes a specific compensation event.
• Other services that have successfully completed their part listen for these compensation events.
• Upon receiving a compensation event, they execute their own rollback logic.

Compensation events must contain enough information for services to perform their rollback. Key details often include:

• The original saga ID or transaction ID.
• Details about the original action that needs to be reversed.
• Any data required to perform the reversal (e.g., amount to refund, item to unreserve).

Consider an online order process:

1. Order Service: Creates order (publishes OrderCreated)
2. Payment Service: Processes payment (publishes PaymentProcessed)
3. Inventory Service: Reserves stock (publishes InventoryReserved)

What if the Inventory Service fails to reserve stock?

If the Inventory Service fails to reserve stock, it should:

• Not publish InventoryReserved.
• Instead, publish a compensation event, like InventoryReservationFailed.

This event signals to other services that the saga could not complete successfully and they need to undo their actions.

The Payment Service is subscribed to events that indicate failures. When it receives InventoryReservationFailed, it knows it needs to act:

• It will initiate a refund for the payment it previously processed.
• After refunding, it might publish a new event, like PaymentRefunded, to inform other interested services.

The Order Service, having created the initial order, also needs to react. It might listen for InventoryReservationFailed or PaymentRefunded.

• Upon receiving such an event, the Order Service updates the order's status to 'Cancelled' or 'Failed'.
• This ensures the user sees an accurate status for their order.

Each service must contain logic to handle both successful forward-progress events and specific compensation events. This often means having separate event handlers for each.

Here's a simplified example of how a Payment Service might listen for a compensation event and trigger a refund:

In a choreography saga, if the 'Inventory Service' fails to reserve items after 'Payment Service' has processed a payment, what is the primary purpose of the 'Inventory Service' publishing an InventoryReservationFailed event?

You've learned how critical compensation is in choreography sagas to maintain data consistency in distributed systems. Key takeaways:

• Compensation reverses successful actions when a saga step fails.
• In choreography, services publish specific compensation events to initiate rollbacks.
• Each service must implement logic to listen for and react to these events, performing its own undo operations.
• Clear event design and robust handling are essential for resilient sagas.