Transaction Control (ACID): Real-World
Module: Data Modification & Transactions
Stripe processes 1 billion payment transactions daily using ACID transactions to ensure money transfers are atomic (debit and credit both succeed or both fail). Amazon uses transactions for order placement: reserve inventory, charge payment, create order record - all must succeed together or rollback. Uber uses transactions for ride booking: update driver status, create ride record, charge customer - atomic operation prevents double-booking. Netflix uses transactions for subscription changes: update plan, prorate charges, send confirmation - consistency guaranteed. Banks use transactions for money transfers: debit source account, credit destination account, log transaction - atomicity prevents money loss. ACID transactions are critical for financial systems, e-commerce, booking systems, and any application requiring data consistency.
Stripe: Process 1 Billion Payment Transactions Daily with ACID Guarantees
Stripe processes 1 billion payment transactions daily for millions of businesses. Each payment requires: (1) Charge customer account, (2) Credit merchant account, (3) Log transaction for compliance. Requirements: Atomicity (both charge and credit succeed or both fail), consistency (balances stay ≥ 0), isolation (concurrent payments do not interfere), durability (committed payments survive crashes). Traditional approach: Separate UPDATE statements without transaction. Problem: Charge succeeds but credit fails (money disappears), or concurrent payments cause negative balance. Solution: Use ACID transactions with error handling, retry logic, and audit logging.
Stripe transaction pattern: (1) BEGIN transaction, (2) Lock customer account (FOR UPDATE), validate balance ≥ amount, (3) Debit customer account, (4) Credit merchant account, (5) Insert transaction log (compliance), (6) COMMIT (all succeed together). Error handling: TRY-CATCH block catches errors (insufficient funds, account not found), automatically rolls back transaction, logs error. Retry logic: Catch deadlock error, wait random time (100-500ms), retry up to 3 times (99% success after retries). Performance: Transaction duration < 50ms (fast), lock ordering prevents deadlocks (90% reduction), index account_id for fast lookups (10x speedup).
-- Stripe payment processing with ACID guarantees
CREATE OR REPLACE FUNCTION process_payment(
customer_id_param BIGINT,
merchant_id_param BIGINT,
amount_param DECIMAL(10,2),
currency_param VARCHAR(3),
max_retries INT DEFAULT 3
) RETURNS TABLE(
payment_id BIGINT,
status TEXT,
retry_count INT
) AS $$
DECLARE
payment_id_var BIGINT;
customer_balance DECIMAL(10,2);
merchant_balance DECIMAL(10,2);
retry_count_var INT := 0;
retry_delay FLOAT;
BEGIN
-- Retry loop for deadlock handling
LOOP
BEGIN
-- Step 1: Lock accounts in consistent order (prevent deadlock)
IF customer_id_param < merchant_id_param THEN
SELECT balance INTO customer_balance
FROM accounts WHERE account_id = customer_id_param FOR UPDATE;
SELECT balance INTO merchant_balance
FROM accounts WHERE account_id = merchant_id_param FOR UPDATE;
ELSE
SELECT balance INTO merchant_balance
FROM accounts WHERE account_id = merchant_id_param FOR UPDATE;
SELECT balance INTO customer_balance
FROM accounts WHERE account_id = customer_id_param FOR UPDATE;
END IF;
-- Step 2: Validate accounts and balance
IF customer_balance IS NULL THEN