When to use 2PC, sagas or just auto-commit for microservices applications

By Nikita Dumkin (nadumkin@edu.hse.ru)

Microservices architecture has become a popular choice for designing scalable and maintainable software systems. However, ensuring data consistency across distributed services presents significant challenges. Techniques such as Two-Phase Commit (2PC), sagas, and auto-commit transactions offer solutions for managing distributed transactions. This essay evaluates when to use each approach in microservices applications, emphasizing their advantages, limitations, and use cases.

In distributed systems, consistency is a key component of the CAP theorem, which states that a system cannot simultaneously guarantee consistency, availability, and partition tolerance. Microservices often prioritize availability and partition tolerance, necessitating specialized approaches to maintain consistency. Transactions in microservices involve multiple services interacting, which raises the question of how to handle data integrity effectively.

Traditional database techniques, such as 2PC, ensure strong consistency but may degrade performance and availability. In contrast, sagas provide eventual consistency but require careful orchestration. Auto-commit, which relies on the inherent atomicity of single-service operations, may suffice in simpler scenarios. Understanding the trade-offs between these techniques is critical for designing resilient microservices systems.

Two-Phase Commit is a distributed transaction protocol that ensures atomicity by coordinating operations among multiple services through a transaction manager. It involves two phases: a preparation phase, where all participants confirm readiness, and a commit phase, where changes are finalized. This approach guarantees strong consistency but introduces high latency and potential performance bottlenecks, particularly in the event of participant or network failures. It is best suited for scenarios where data integrity across services is paramount and can tolerate the associated overhead.

Sagas, on the other hand, offer a decentralized approach to managing distributed transactions by breaking them into a series of smaller, independent steps. Each step is a transaction in itself, capable of committing changes independently. If a failure occurs at any step, compensatory actions are executed to undo the changes. Sagas can be implemented using orchestration, where a central controller manages the sequence, or choreography, where each service reacts to events emitted by others. This method provides eventual consistency and is more scalable than 2PC but requires meticulous error handling to ensure consistency.

Auto-commit transactions are the simplest form of consistency management, where each database operation is committed immediately upon execution. This approach is lightweight and effective for operations confined to a single service or database. It avoids the overhead of coordination mechanisms but lacks the capability to handle distributed or dependent operations. Auto-commit is ideal for isolated tasks where the consistency requirements are minimal.

Two-Phase Commit is a fundamental distributed algorithm that ensures atomicity in transactions involving multiple systems. In a distributed database environment, where a single transaction spans multiple nodes, achieving consistency is critical. The 2PC protocol addresses this challenge by coordinating all participating systems to either commit or roll back changes as a unified operation. This essay explores the mechanics of 2PC, its advantages, limitations, and applications in distributed systems.

The Two-Phase Commit protocol operates in two stages: the prepare phase and the commit phase. During the preparation phase, the coordinator node sends a request to all participants to prepare for the transaction. Each participant executes the transaction locally but does not commit it, ensuring readiness to proceed. The participants then respond to the coordinator with either approval to commit or a refusal based on local conditions.

If all participants signal readiness, the process advances to the commit phase. The coordinator instructs each participant to commit the transaction, finalizing the changes. If any participant refuses or fails to respond during the prepare phase, the coordinator sends instructions to roll back, ensuring that no changes are committed. This two-stage structure guarantees that all nodes either commit their changes collectively or abandon the transaction altogether, maintaining the atomicity and consistency of the system.

In distributed systems, managing transactions across multiple independent services poses significant challenges. Traditional transaction management techniques, such as the two-phase commit protocol, are often unsuitable due to high coordination overhead and limited scalability. To address these limitations, the concept of sagas has emerged as a decentralized approach for handling distributed transactions. This essay explores the definition of sagas, their core principles, and their application in modern distributed architectures.

Sagas represent a pattern for managing distributed transactions in a decentralized and reliable manner. This concept, introduced by Hector Garcia-Molina and Kenneth Salem in 1987, involves dividing a long-running transaction into smaller, independent steps or sub-transactions. Each step is executed sequentially, and if one fails, a compensating action is triggered to undo the effects of the preceding steps. This mechanism ensures eventual consistency without requiring a centralized transaction coordinator.

The key characteristics of sagas include decentralization, where each service involved manages its operations and compensating actions independently; eventual consistency, which ensures all services achieve a consistent state over time, even in the presence of failures; and reliance on compensation logic, which avoids immediate rollbacks by addressing errors through compensating actions.

There are two primary execution models for sagas: choreography and orchestration. In the choreography model, services communicate with each other using events, performing operations and emitting new events as required. This model promotes loose coupling but increases system complexity due to the lack of centralized control. Conversely, the orchestration model uses a central orchestrator to coordinate the execution of sub-transactions and compensations. The orchestrator issues commands, tracks progress, and handles failures. While orchestration simplifies control, it introduces a single point of dependency.

Auto-commit is a mechanism in database management systems that automatically applies changes to a database without requiring explicit user intervention. This feature serves as an essential tool for consistency management by ensuring that database states remain stable and predictable. By automating the process of committing transactions, auto-commit minimizes the risk of data loss and simplifies transaction handling, especially in environments with high operational demands. This essay examines the concept of auto-commit, its role in maintaining database consistency, and its practical applications in various systems.

Transactions in databases are defined as a sequence of operations that must be executed as a single unit to maintain consistency and integrity. Normally, transactions require explicit commands to finalize changes (commits) or revert them (rollbacks). Auto-commit simplifies this process by treating each SQL statement as a standalone transaction that is committed immediately after execution. This eliminates the need for manual transaction management by the user. Auto-commit is a default feature in many relational database management systems, including MySQL, PostgreSQL, and Oracle.

Auto-commit contributes significantly to ensuring consistency in database systems, particularly by upholding the ACID properties of transactions. In terms of atomicity, each statement is executed in its entirety or not at all, ensuring that partial changes do not occur. Immediate commits ensure that the database transitions directly from one valid state to another, maintaining consistency. Isolation is preserved through system-level mechanisms like locking, which prevent interference between parallel transactions. Finally, durability is guaranteed as changes are written to persistent storage as soon as they are committed, ensuring that data remains intact even in the event of a system failure.

Fig 1. Comparison between 2PC, Sagas and Auto-Commit

Two-Phase Commit should be employed in systems where strong consistency is absolutely essential. For instance, financial applications often require guarantees that transactions either fully succeed or fully fail to maintain data integrity. While 2PC introduces significant latency and complexity due to its reliance on a central coordinator, its robustness in handling distributed operations across services or databases makes it a viable option for critical use cases.

Sagas are better suited for scenarios where eventual consistency is sufficient and operations involve long-running processes. Applications like order processing in e-commerce platforms exemplify such use cases. By dividing workflows into smaller, autonomous transactions, sagas enable the system to remain operational even when a failure occurs. The use of compensatory transactions ensures that the system can recover gracefully from errors. However, designing and implementing sagas requires careful attention to error handling and coordination to avoid inconsistencies.

Auto-commit is an appropriate choice for operations confined to a single service or database. For example, logging operations or simple CRUD tasks can rely on auto-commit to achieve atomicity without the overhead of distributed transaction management. While this approach lacks the capability to coordinate changes across services, it is highly performant and straightforward, making it ideal for use cases with minimal consistency requirements.

The choice between 2PC, sagas, and auto-commit involves trade-offs in system design. While 2PC guarantees atomicity, its locking mechanisms can impede scalability. Sagas, offering flexibility through compensations, demand robust error handling to ensure consistency. Auto-commit is effective for isolated operations but unsuitable for complex workflows. Real-world implementations often blend these techniques. For instance, an e-commerce platform might use sagas for order processing, 2PC for payment settlement, and auto-commit for logging operations. Designing resilient systems requires evaluating business requirements, failure tolerance, and system complexity.

2PC, sagas, and auto-commit represent diverse strategies for managing consistency in microservices applications. Their adoption depends on the specific consistency, performance, and complexity requirements of the system. While 2PC is suitable for scenarios demanding strict atomicity, sagas excel in handling eventual consistency for distributed workflows. Auto-commit remains a simple yet effective choice for isolated transactions.

1. A. Navarro.Fundamentals of Transaction Management in Enterprise Application Architectures. https://doi.org/10.1109/ACCESS.2022.3224759
2. ChatGPT (Scholar GPT). Provide at least 15 sources for: 2PC, Sagas, Auto-Commit, Transaction Management in microservice applications. https://sider.ai/
3. ChatGPT 4o. Write small article and explain what is 2PC and describe it's usage. https://chatgpt.com/
4. ChatGPT 4o. Write small article and explain what are Sagas and describe their usage. https://chatgpt.com/
5. ChatGPT 4o. Write small article and explain what is Auto-Commit and describe it's usage. https://chatgpt.com/
6. Fan, P., Liu, J., Yin, W. et al. 2PC*: a distributed transaction concurrency control protocol of multi-microservice based on cloud computing platform. J Cloud Comp 9, 40 (2020). https://doi.org/10.1186/s13677-020-00183-w
7. Hedgpeth, R. (2021). Managing Transactions. In: R2DBC Revealed. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-6989-3_14
8. JJ Dijkstra. Zero-downtime schema changes. https://research.utwente.nl/files/275963001/PDEng_Thesis_Public_Jorryt_Jan_Dijkstra.pdf
9. K. Munonye, P. Martinek. Enhancing Performance of Distributed Transactions in Microservices via Buffered Serialization. https://doi.org/10.13052/jwe1540-9589.19564
10. K. M. Koyya, B. Muthukumar.A Survey of Saga Frameworks for Distributed Transactions in Event-driven Microservices. https://doi.org/10.1109/ICSTCEE56972.2022.10099533
11. M. Gördesli, A. Nasab and A. Varol. Handling Rollbacks with Separated Response Control Service for Microservice Architecture. https://doi.org/10.1109/IISEC56263.2022.9998226
12. TK Abuya, RM Rimiru, WK Cheruiyot. An Improved Failure Recovery Algorithm In Two-Phase Commit Protocol For Transaction Atomicity. https://www.academia.edu/download/98746339/an-improved-failure-recovery-algorithm-in-twophase-commit-protocol-for-transaction-atomicity.pdf
13. Z. Wang, C. Tang, X. Zhang, Q. Yu, B. Zang, H. Guan, H. Chen. Ad Hoc Transactions through the Looking Glass: An Empirical Study of Application-Level Transactions in Web Applications. https://doi.org/10.1145/3638553