SQL Practice Logo

SQLPractice Online

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