-
Notifications
You must be signed in to change notification settings - Fork 0
Distributed Transactions
Single logical unit of work that spans multiple systems, often involving different databases or microservices.
- Goal is to ensure that all the operations within the transaction either succeed completely (commit) or fail completely (rollback), maintaining data consistency across the distributed system.
- Distributed nature ➟ introduces complexities not present in traditional, single-database transactions.
- Network latency, partitions and failures can disrupt communication between systems, making it difficult to coordinate transaction completion.
- Individual systems within the distributed transaction might fail independently.
- Ensuring atomicity (all or nothing) becomes challenging.
[3.] Consistency Models ◾ Distributed systems often employ weaker consistency models (e.g., eventual consistency) than the strong consistency typically found in single-database transactions. ◾ This can lead to temporary inconsistencies that need to be managed carefully.
[4.] Concurrency Control ◾ Concurrent access to data across different systems can lead to conflicts and race conditions, requiring sophisticated concurrency control mechanisms.
The ACID properties (Atomicity, Consistency, Isolation, Durability), become more difficult to guarantee in a distributed environment.
- Two-Phase Commit (2PC)
- Phase 1 (Prepare) - Coordinator sends a 'prepare' message to all participants. Each participant checks if it can commit the transaction and responds with a 'yes' (prepared) or 'no' (abort).
- Phase 2 (Commit/Abort) - If all participants vote 'yes,' the coordinator sends a 'commit' message. If any participant voted 'no' or didn't respond, the coordinator sends an 'abort' message.
Participants execute the corresponding action.
- Orchestration - A central orchestrator coordinates the saga, sending commands to participants and handling responses.
- Choreography - Participants react to events published by other participants, leading to a decentralized coordination.
- **Compensating Transactions **- Each step in the saga has a corresponding compensating transaction that can undo its effects in case of failure.
- A relaxed consistency model.
- BASE stands for - Basically Available, Soft state, Eventual consistency.
- Try - Reserve resources required for the transaction.
- Confirm - If all resources are reserved, execute the operations.
- Cancel - If any resource reservation fails, release all reserved resources.
There are more approaches like Quorum-based Consensus (Paxos, Raft), Distributed Locking, Transactional Outbox Pattern etc.