تصميم Sagas مدفوعة بالأحداث

Welcome! In this lesson, we'll learn how to design the flow of a Choreography Saga. This pattern helps manage complex business transactions that span multiple services.

We'll focus on using events as the primary way services communicate and trigger each other's actions.

Remember Choreography Sagas? In this style, services communicate directly by publishing and subscribing to events.

• No central orchestrator: Services react to events from others.
• Decentralized decisions: Each service decides its next step based on the event it receives.

Let's design a saga for an "Online Order Placement" system. This common scenario involves several steps across different microservices:

• Customer places order.
• Inventory is checked and reserved.
• Payment is processed.
• Order is shipped.

For our "Order Placement" saga, we can break it down into these main steps, each potentially handled by a different service:

• Order Service: Creates the order.
• Inventory Service: Reserves items.
• Payment Service: Processes payment.
• Shipping Service: Schedules shipment.

In a choreography saga, each step is initiated by an event. When one service completes its task, it publishes an event.

Other services, interested in that event, subscribe to it and react accordingly. This creates a chain reaction.

Every saga needs a starting point. For our "Order Placement," the Order Service initiates the process.

When a customer places an order, the Order Service creates it and publishes an OrderCreatedEvent.

The Inventory Service subscribes to OrderCreatedEvent. Upon receiving it, it attempts to reserve the items for the order.

After processing, it publishes either an InventoryReservedEvent or an InventoryFailedEvent.

The Payment Service subscribes to InventoryReservedEvent. This means payment only proceeds if inventory is successfully reserved.

It processes the payment and then publishes either a PaymentProcessedEvent or a PaymentFailedEvent.

Finally, the Shipping Service subscribes to PaymentProcessedEvent. It schedules the shipment only after payment is confirmed.

It then publishes an OrderShippedEvent to complete the main saga flow.

What if a step fails? For example, if payment fails after inventory is reserved? In a choreography saga, we use compensation events.

The Payment Service would publish a PaymentFailedEvent. The Inventory Service would subscribe to this event and publish an InventoryReleasedEvent to undo its previous action.

We've learned how to design a choreography saga by breaking down a business transaction into steps.

• Each step publishes an event to trigger the next.
• We identified the initial event and subsequent events for a successful flow.
• We also briefly considered how compensation events are used to handle failures.

Next, we'll explore how message brokers facilitate this communication!