Transactions in Microservices

Since we can't use SQL transactions across services, we use the Saga Pattern. A Saga is a sequence of local transactions where each step has a "Compensating Action" to undo the work if a later step fails.

1. Choreography (Event-Based)

Each service does its work and publishes an event. The next service listens and does its work. - **Pros:** No central point of failure, very decoupled. - **Cons:** Hard to keep track of the 'State' of the whole process. Best for simple, linear workflows.

2. Orchestration (Centralized)

One service (The Orchestrator) acts as the 'Director'. It tells Service A to work, waits for the result, then tells Service B. - **Pros:** Easy to see exactly where an order is stuck. - **Cons:** The Orchestrator can become a 'Fat Service' that contains too much business logic. **Architect Tip:** Use **MassTransit State Machines** to implement Orchestration. It provides a visual, testable way to manage complex multi-service workflows.

4. Interview Mastery

Q: "What is a 'Compensating Transaction'?"

Architect Answer: "It is an 'Undo' operation. If the 'Payment' service succeeds but the 'Shipping' service fails because the address is invalid, the Saga must trigger the 'Refund' action in the Payment service. We don't 'Delete' the old record; we create a new 'Reversal' record to maintain a perfect audit trail."