#25Payment / Wallet System
Idempotent, double-entry, sagas vs 2PC.
Build a payment / wallet system that accepts charges, moves money across accounts, and never loses or double-applies a transaction — even when the network drops, the database fails over, or a third-party acquirer returns 503 mid-charge. The architectural pressure here isn't QPS (Stripe-scale is ~10K charges/sec sustained, well within reach of a sharded Postgres) — it's **correctness under retry**, **invariant preservation across services**, and **survivable failure modes**. Three load-bearing concepts: 1. **Idempotency** — every mutating call is keyed and replayable, with state-machine semantics so a crashed-and-retried client gets the same answer (Stripe / Brandur / Airbnb Orpheus). 2. **Double-entry, immutable journal + projected balances** — the ledger is append-only; balances are derived (Square Books, Monzo, Uber Gulfstream). 3. **Saga (not 2PC) for cross-service money movement** — durable workflow engine drives multi-step charges with explicit compensations (Uber Cadence / Temporal, Airbnb Skipper).
Reading: Brandur — Implementing Stripe-like Idempotency Keys in Postgres · Stripe — Designing robust APIs with idempotency · Square — Books: an immutable double-entry accounting database · Monzo — Speeding up balance reads (ledger) · Uber — Engineering Uber's Next-Gen Payments Platform (Gulfstream) · Airbnb — Avoiding double payments (Orpheus) · Garcia-Molina & Salem — Sagas (1987) · Debezium — Outbox pattern
idempotency
double-entry
sagas
reconciliation
outbox
compensation