In a long transaction where multiple sub transactions happen in different services, if one transaction fails, works of other services should be rolled back as well
- Orchestration: (SYNCHRONOUS) A central service acting as an orchestrator calls other services in the due order and if there happens to be a failure, it'll compensate by calling compensating actions on other services it called before. This way, one step must be successful before continuing, so it waits for responses, meaning it's synchronous.
- Choreography: (ASYNCHRONOUS) No central service. Services react to events and decide what to do/ what to compensate. e.g. when client puchasedgoods, if it failed, it sends FAIL event to MQ, maybe a notification service subscribing to this FAIL event will react on this and nothing else, else if it succeeds, it sends SUCCESS event to MQ, other services like inventory, user history, shipping will react on this. (this is spanning, aka saga)
The dual write problem, when data needs to be persisted and notification for that event is published onto the MQ. These 2 operations talk to separate systems and our transaction cant cover both of them -> inconsistent state
Domain data and log of domain events are persisted in the same db, within the same transaction. and there exists a separate process (periodically) consuming events from the outbox (events log) table and publish to the MQ.
Using dbs that support transactions