Design Payment System (Stripe-style)

Зачем нужно знать

Платежная система выглядит как обычный CRUD только до первого сбоя. В реальности это система, где одна потерянная запись, один повторный retry или один неверно обработанный webhook превращаются в реальные деньги: двойное списание, потерянный capture, неправильный refund, расхождение с банком и ручной разбор в поддержке. Поэтому кейс учит не просто подключать PSP, а проектировать финансовый workflow с нулевой терпимостью к потере данных.

В этом разборе используется учебный workload: 100M transactions/day дают примерно 1.16K операций в секунду в среднем; peak 12K RPS означает коэффициент около 10.4. Capacity надо считать отдельно для API, provider calls, journal lines, outbox и webhook attempts. Для денежного core цель — не потерять подтвержденную локальную проводку; неизвестные внешние outcomes восстанавливаются по provider reference и reconciliation, потому что одно обещание RPO=0 без описания fault domain ничего не доказывает.

Главная польза кейса: он связывает [CONCEPT]idempotency, Saga Orchestration, Transactional Outbox, [CONCEPT]consistency-models и [CONCEPT]database-internals-overview в одну практическую архитектуру. Здесь хорошо видно, почему сильная консистентность нужна в ledger, почему внешние вызовы нельзя держать внутри долгой SQL-транзакции, и почему retry должен быть штатным сценарием, а не исключением.

Mental model

Думайте о payment system как о state machine вокруг денежного намерения. payment_intent проходит состояния processing, requires_action, authorized, capture_pending, captured, failed; refund является отдельной сущностью со своей state machine. Каждый переход идемпотентен и аудируем. Локальная истина — journal и payment state, а расхождение с provider state разрешает reconciliation; HTTP response сам по себе не является денежным фактом.