choreography | Explore all the events from your Microservice | Microservice library

The two are compatible patterns that address different problems, Sagas handle workflow processes where as event sourcing addresses how state is stored. Sagas provide a mechanism for handling a multi-step process and rolling back should steps fail (like a workflow). Where as Event Sourcing is the process of encoding the state of an entity by recording all its past changes.

Lets say we are booking a holiday, we need to book flights, a hotel and hire a car. each of these processes is handled by a different microservice.

We could create a microservice named BookingSaga which would be responsible for keeping track of the state of each booking. When we make a booking the BookingSaga service would

• book the hotel
• book the flight
• book the car

these can reply in any order, but if any one fails the BookingSaga would then begin a rollback and cancel any that had already been booked.

https://microservices.io/patterns/data/saga.html

Event sourcing keeps track of the state of some entity by recording the changes that have happened to it.

• Object A Name changed to "dave"
• Object A Age Changed to 3
• Object A Named changed to "sue"

So we can see that Object A has a name of "sue" and an Age of 3 at the end of all the events. https://microservices.io/patterns/data/event-sourcing.html

If I understand correctly you are receiving a request or a message which contains information to create an employee. One of those field is department name or id. And you would like to validate existence of this department information from department service. Is my understanding correct? If so I would say a lot easier solution would be keeping a basic department data on your employee service. You can get department created, updated events from department service and sync your data instead of asking for each and every employee.

With this solution you wont have a dependency between services. You will just listen the topic or queue to which you wont know where the message comes from which is total opposite of the coupling.

I think using Choreography rather then Orchestration for distributed transactions makes sense if you chose it for the right reasons. For instance, if you need to spare the usually higher effort of implementing a central choreography as you don't need to know what state a transaction is in until it has finished. Or because you know that the order of the transaction workflow is stable and is unlikely to change which would also be on the plus side of choreography. But would be a drawback for Choreography if the order changes frequently because you would need to adapt all microservices in that case...

So you need to know the advantages and drawbacks of the two approaches.

If you chose Choreography for the right reasons I would say that I am missing the compensation logic in your considerations. What if the credit was reserved but then the order fails in the order service? Compensation events need to be considered as well in such cases...

Other than that there is the usual suspects:

• such as making sure that each service will reliably send the next event after it processed the received event. For this you could look into the Transactional Outbox pattern.
• or making sure that you have deduplication of events implemented in each of the services as for reliable sending of events accross distributed transactions you cannot be a hundred percent sure that an event will only be sent once.

And if you are even interested in an alternative to the Saga pattern you can look into the Routing Slip pattern. It is well suited for distributed transaction workflows that will differ depending on the current use case by avoiding that each service needs to know each route. The sequence of the workflow is attached to the initial message of the transaction and all subsequent messages. Then each service receiving a message with the routing slip performs its tasks and passes the next message including the routing slip to the next station (service) on the list.

Note: I am not sure what exactly you mean by ...IntegrationEvent. I would not differentiate between domain and integration events, all events are relevant from the business perspective in your example otherwise they would not be relevant to other Microservices.

Saga is not an abbreviation. The term “saga” was first defined in a 1987 publication. It also mentions that it was proposed by Bruce Lindsay.

In their original version, the term saga refers to Long Lived Transactions(LLT).

A LLT is a saga if it can be written as a sequence of transactions that can be interleaved with other transactions.

The reason for choosing the word itself is not disclosed. Perhaps one of the literary meanings of the word saga was meant:

a long, detailed story of connected events

Use three COUNTIFS that check if any do not match:

TLDR: Choreography is the one which doesn't need persistance of the status of the process, orchestration needs to keep the status of the process somewhere.

I think you got this somewhat mixed up with implementation details.

Orchestration is called such, because there is a central process manager (sometimes mentioned as saga, wrongly imho) which directs (read orchestrates) operations across other services. In this pattern, the process manager directs actions to BC's, but needs to keep a state on previous operations in order to undo, roll back, or take any corrective or reporting actions deemed necessary. This status can be held either in an event stream, normal form db, or even implicitly and in memory (as in a method executing requests one by one and undoing the previous ones on an error), if the oubound requests are done through web requests for example. Please note that orchestrators may use synchronous, request-response communication (like making web requests). In that case the orchestrator still keeps a state, it's just that this state is either implicit (order of operations) or in-mem. State still exists though, and if you want to achieve resiliency (to be able to recover from an exception or any catastrophic failure), you would again need to persist that state on-disk so that you could recover.

Choreography is called such because the pieces of business logic doing the operations observe and respond to each other. So for example when a service A does things, it raises an event which is observed by B to do a follow up actions, and so on and so forth, instead of having a process manager ask A, then ask B, etc. Choregraphy may or may not need persistance. This really depends on the corrective actions that the different services need to do.

An example: As a practical example, let's say that on a purchase you want to reserve goods, take payment, then manifest a shipment with a courier service, then send an email to the recipient.

The order of the operations matter in both cases (because you want to be able to take corrective actions if possible), so we decide do the payment after the manifestation with the courier.

With orchestration, we'd have a process manager called PM, and the process would do:

1. PM is called when the user attempts to make a purchase
2. Call the Inventory service to reserve goods
3. Call the Courier integration service to manifest the shipment with a carrier
4. Call the Payments service to take a payment
5. Send an email to the user that they're receiving their goods.

If the PM notices an error on 4, they only corrective action is to retry to send the emai, and then report. If there was an error during payment then the PM would directly call Courier integration service to cancel the shipment, then call Inventory to un-reserve the goods.

With choreography, what would happen is:

1. An OrderMade event is raised and observed by all services that need data
2. Inventory handles the OrderMade event and raises an OrderReserved
3. CourierIntegration handles the OrderReserved event and raises ShipmentManifested
4. Payments service handles the ShipmentManifested and on success raises PaymentMade
5. The email service handles PaymentMade and sends a notification.

The rollback would be the opposite of the above process. If the Payments service raised an error, Courier Integration would handle it and raise a ShipmentCancelled event, which in turn is handled by Inventory to raise OrderUnreserved, which in turn may be handled by the email service to send a notification.

OpenShift as a Kubernetes fork and vendor is free to invent whatever new terminology they want for marketing purposes. None of these terms have formal definitions in the first place, but even without that marketing is its own domain and rarely bound by such things. My guess is their marketing team thinks "choreography" conjures a feeling of overall poise and balance? Which the think aligns with their brand in some way.

tl;dr it's advertising, not technical terms.