Managing Distributed Transactions
1. Understanding ACID vs BASE Properties
| Property | ACID | BASE |
|---|
| Consistency | Strong | Eventual |
| Availability | May sacrifice | Prioritized |
| Use | Single-DB tx | Distributed services |
| Examples | Postgres, MySQL InnoDB | DynamoDB, Cassandra |
2. Understanding Two-Phase Commit
| Phase | Action |
|---|
| 1. Prepare | Coordinator asks all RMs to vote |
| 2. Commit/Abort | If unanimous yes → commit; else abort |
| Issues | Blocking, coordinator SPOF, poor scale |
| Verdict | Avoid in microservices; use sagas |
3. Implementing Saga Pattern
| Concept | Detail |
|---|
| Saga | Sequence of local transactions across services |
| Forward step | Performs business action |
| Compensation | Semantic undo of completed step |
| Failure recovery | Run compensations in reverse |
Order ─► Pay ─► Reserve ─► Ship (forward)
◄─Refund◄─Release ◄─Cancel (compensation)
4. Using Compensating Transactions
| Forward | Compensation |
|---|
| Charge payment | Refund |
| Reserve inventory | Release reservation |
| Send confirmation email | Send cancellation email |
| Allocate shipping label | Void label |
Warning: Compensations are semantic, not technical rollbacks — design with business intent.
5. Implementing Saga Orchestration
| Aspect | Detail |
|---|
| Central orchestrator | Sends commands, tracks state machine |
| Pros | Easy to reason; centralized monitoring |
| Cons | Orchestrator becomes complex |
| Tools | Camunda, Temporal, Step Functions, Axon |
6. Implementing Saga Choreography
| Aspect | Detail |
|---|
| Event-driven | Each service reacts to prior service's event |
| Pros | No central point; loose coupling |
| Cons | Hard to trace; cyclic dependencies risk |
| Best for | Simple flows, ≤ 3 services |
7. Handling Transaction Isolation
| Issue | Mitigation |
|---|
| Lost updates | Optimistic locking + version |
| Dirty reads (saga in-flight) | Mark records "pending"; filter from queries |
| Fuzzy reads | Idempotent writes; semantic locks |
| Pattern | Saga isolation: pivot transaction, semantic lock |
8. Managing Transaction Timeouts
| Scope | Default |
|---|
| DB transaction | 1–30s |
| Saga step | Per-step deadline |
| Whole saga | Minutes–hours; trigger compensations on expiry |
| Tooling | Temporal: built-in workflow timers |
9. Implementing Idempotency
| Technique | Detail |
|---|
| Idempotency key | Per request unique ID |
| Natural ID | Use business key (orderId) |
| Conditional update | WHERE version = ? |
| Dedup table | Insert key with unique constraint |
10. Using Event-Driven Consistency
| Element | Detail |
|---|
| Domain event | Fact published on success |
| Subscribers | Update local projections |
| Outbox | Atomic write + publish |
| Idempotent consumer | Safe replay |
11. Handling Partial Failures
| Scenario | Action |
|---|
| Step succeeds, ack lost | Idempotent retry safe |
| Step fails mid-way | Compensate completed steps |
| Compensation fails | Retry; alert on persistent failure (manual fix) |
| Service down | Resume from durable state when up |
12. Managing Transaction Logs
| Element | Purpose |
|---|
| Saga log | Persisted state of each step |
| Audit trail | Who/what/when for compliance |
| Replay | Recover after crash |
| Retention | Match regulatory/business needs |