#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