End-to-end payment processing: authorization, capture, settlement, refunds/chargebacks, with multi-provider failover, strong consistency for balances, and full audit trail.
Single service handles checkout + payments + webhooks with one database.
What was missing: Ingress protection, PCI isolation, async workflows, and auditing.
Why that's risky: SPOF and blocked user flows under spikes.
What gets added: Nothing yet (MVP).
Trade-offs: Fast to ship; not production-ready.
Add ingress protection and split checkout from persistence.
What was missing: Edge protection and separate compute.
Why that's risky: Origin overload; no quotas.
What gets added: Edge + throttling + Checkout API.
Trade-offs: Quota config overhead.
Isolate PCI scope; add risk checks, outbox, and background processing.
What was missing: PCI isolation, reliable events, and async workflows.
Why that's risky: Coupling leads to duplicate charges/timeouts on spikes.
What gets added: PCI service, risk checks, outbox, queue, and workers.
Trade-offs: Operational complexity of background fleet.
Abstract providers, add failover, centralize secrets, and handle poison jobs.
What was missing: Provider abstraction, failover, secret management, and DLQ.
Why that's risky: Vendor lock-in/outages; opaque credentials; stuck poison jobs.
What gets added: Provider gateway, KMS, DLQ and handlers; multi-provider writes.
Trade-offs: More moving parts and operational overhead.
Add immutable double-entry ledger and reconciliation workflows.
What was missing: Correct balance tracking and external reconciliation.
Why that's risky: Revenue leakage and compliance gaps.
What gets added: Ledger service/DB, webhook ingest, and reconciliation worker.
Trade-offs: Operational/static data growth and compaction.
Harden production with SCA, monitoring, replicas, and chargeback workflows.
What was missing: SCA, deep observability, and read scale for analytics/support.
Why that's risky: Compliance failures, blind spots, and slow reads under load.
What gets added: 3DS/SCA, monitoring, read replica; chargeback workflow.
Trade-offs: Increased operational cost/complexity.
Require client-supplied idempotency keys and store them with final outcomes. For async steps, use outbox tables and idempotent workers keyed by (intent_id, step). Expire keys conservatively and reject conflicting replays.
Route through a provider gateway with health-checked providers and circuit breakers. Persist provider-of-record with each charge, and reconcile later if a failover provider captured the payment to avoid duplicates.
Double-entry ensures every debit has a credit, enabling invariant checks. Postings are immutable and append-only; balances derive from sums. Corrections are new reversing entries, never mutations.
Track auth/capture/refund success rates, tail latencies, queue depths, retry counts, provider error taxonomy, and ledger drift. Create SLOs with burn-rate alerts on user-facing metrics.
Model refunds as new negative postings tied to the original charge. Chargebacks create dispute holds and postings; evidence workflows run via background workers with strict idempotency and audit logs.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own: