BASE, Two Phase Commit and Saga
Let us assume our application has 3 microservices.
1. Order Service: Manages orders placed by customers.
2. Inventory Service: Manages product stock levels.
3. Payment Service: Handles payment processing.
Introduction to BASE
Distributed systems often adopt the BASE principle over strict consistency for scalability and availability:
• Basically Available: Guarantees that the system remains available for most operations, even under failure conditions.
• Soft state: The state of the system may change over time, even without external input (due to eventual consistency).
• Eventual consistency: Guarantees that the system will become consistent eventually, as updates propagate.
Example: When a user places an order, services work asynchronously to ensure stock is deducted, payment is processed, and the user is notified. The consistency of all services is eventually achieved.
Handling transactions
1) 2 PC and 2) Saga
1. Two-Phase Commit (2PC)
2PC ensures atomic consistency across distributed services by coordinating operations in two phases: Prepare and Commit/Abort.
How It Works:
1. Prepare Phase:
o A coordinator service initiates the transaction and asks all participating services (e.g., Order, Inventory, Payment) to "prepare" for the operation.
o Each service checks if it can perform the operation (e.g., sufficient stock or payment approval) and locks the necessary resources.
o Services respond to the coordinator with a yes (prepared) or no (abort).
2. Commit Phase:
o If all services respond with yes, the coordinator sends a commit message to all participants, finalizing the transaction.
o If any service responds with no, the coordinator sends an abort message to roll back any partial changes.
Example:
1. The user places an order.
2. The coordinator sends a prepare request:
o Order Service reserves the order.
o Inventory Service locks stock.
o Payment Service holds the payment amount.
3. If all services respond with "prepared," the coordinator sends a commit:
o The order is finalized, stock is deducted, and payment is captured.
4. If any service fails, the coordinator sends an abort, rolling back all changes (e.g., releasing stock and refunding payment).
Challenges with 2PC:
• Performance overhead: Locks held during the prepare phase can slow down the system.
• Single point of failure: The coordinator is critical and can become a bottleneck.
• Not resilient to partial system failures or partitions.
#microservices #cloudnative