In FinTech, we’re not just shuffling database rows; we’re handling people’s savings, their money, their future. As a result, correctness, reliability, and predictability are essential system requirements. This mandates an uncompromising standard for data integrity, particularly within the core operation of a transaction.
The Two-Phase Commit for Financial Transactions: Atomicity Of Money
The principle that guarantees this integrity is Atomicity. From a system’s perspective, either all operations within the transaction succeed, or if any part fails, the entire sequence of operations is rolled back, leaving the database state unchanged.
Understanding Atomicity and the ACID Framework
Atomicity in financial transactions is the first and foundational property of the ACID model—a set of four properties (Atomicity, Consistency, Isolation, Durability) that database transactions must possess to ensure reliability and correctness, especially in systems where data integrity is paramount, especially financial services.
Consider a fundamental operation: transferring ₹100 from Account A to Account B. This transaction comprises two distinct operations: debiting ₹100 from Account A and crediting ₹100 to Account B. Atomicity ensures these two operations are treated as a single, inseparable action. If the debit succeeds but the credit aborts due to any error, the atomic transaction mechanism will automatically revert the debit. The result is that the transaction either completes fully, moving ₹100 from one account to the other, or it fails completely, with both account balances remaining as they were. No funds are lost or created incorrectly.
- From Monolith to Distributed Systems:
How Microservices Changed Transaction Atomicity Earlier, when applications were monolithic, this was easy. Everything happened inside a single database, the atomicity was straightforward. You’d initiate a transaction (BEGIN TRANSACTION ), execute all operations, and finally issue a COMMIT. The database ensured the integrity is maintained.
But now architectures, however, have evolved toward Microservices—where one large system is split into many smaller, independent services each with its own private database. The debit operation is performed by a “Ledger Service,” while the credit is handled by a separate “Accounts Service,” communicating over a network.This distribution introduces significant complexity for ensuring Atomicity in Payment Systems
A simple ₹100 transfer is no longer one unified action. One microservice handles debiting the sender’s account, another handles crediting the receiver’s. Since they communicate over a network, problems like timeouts, dropped connections, or partial failures can occur—meaning one step could succeed while another fails.
The transaction is no longer contained within a single database but is spread across multiple, independent systems. Network partitions, service timeouts, hardware failures, or software errors can now cause partial failures: one service may complete its operation while another get disrupted This breach of the atomic guarantee is what leads to critical system failures, such as financial discrepancies where money appears to “disappear.”
So how to guarantee the “all or nothing” principle when a transaction is physically split across independent services?
To maintain the guarantee across distributed services, systems implement coordinated protocols i.e the Two-Phase Commit (2PC). How does two phase commit work in payment systems?
Inside the Two-Phase Commit: Coordinating Distributed Transactions
Two Phase Commit in financial transaction is a distributed algorithm that ensures all participants in a transaction either “all commit” or “all abort”. It is managed and orchestrated by a designated central authority Transaction Coordinator and involves the participating services, known as Cohorts.
The entire process happens in two strictly ordered logged phases.
Note: The cohorts first write the intended changes to a recovery journal, known as the Write-Ahead Log (WAL), before touching the actual data.
This issuer-acquirer transaction lifecycle, whether with the same-network or cross-network, processes prepaid card transactions identically to traditional debit and credit cards for authorization and settlements. Furthermore, Prepaid cards now serve a wide range of banking and financial use cases across consumer and corporate ecosystems.
Consistency vs Availability in Payment Systems
2PC is the engineering baseline for strong consistency—all systems agree fully before anything happens. That’s perfect for preventing loss or mismatch.
But there’s a cost. If the Coordinator crashes after cohorts have voted YES, the other services may remain blocked indefinitely, holding locks while waiting for a decision. They can’t move forward or release their data. This is known as the indefinite blocking problem.
In a payment ecosystem where thousands of transactions happen every second, this delay is dangerous. It can freeze funds, clog processing queues, and hurt user experience.
This is why modern payment systems often move beyond 2PC toward patterns like sagas, compensating transactions, or idempotent workflows—trading strict consistency for availability and resilience.Two-Phase Commit solves Atomicity but blocks systems when coordinators crash. So how do payment giants handle millions of transactions per second? We’ll explore Saga patterns and compensating workflows in our next post.
Author
Sovit Acharya, Principle Engineer
Working at the intersection of technology and finance, building robust systems that enable seamless digital transactions. He is passionate about designing and scaling cloud-native architectures for fintech ecosystems, with expertise in GoLang, Kubernetes, and high-performance distributed systems.
