Day 20/30: Distributed Transactions 📌 How do you keep data consistent when one operation affects multiple services? In a monolith, a transaction can often be handled by a single database. Example: → Create Order → Deduct Payment → Update Inventory But in microservices, these may belong to different services and databases. You can't simply use one traditional database transaction across all of them. One common approach is the Saga Pattern. Example: Order Service ↓ Payment Service ↓ Inventory Service ↓ Order Confirmed If something fails, the system performs a compensating action. Example: Payment succeeds → Inventory fails → Refund payment → Cancel order Two common Saga approaches: → Choreography Services react to events and trigger the next step. → Orchestration A central coordinator tells each service what to do. The difficult part isn't making the transaction work when everything succeeds. It's handling: → Partial failures → Retries → Duplicate events → Timeouts → Data consistency → Rollbacks / compensation System Design takeaway: Distributed transactions are difficult because there is no single database transaction controlling everything. When services own separate data, think: Saga → Events → Idempotency → Compensation Next: Idempotency & Deduplication