Question
Design an idempotent payment-intent flow for a checkout system processing ~2,000 payments/min against an external payment processor (Stripe-like) that itself can be slow or time out. A payment-intent moves through created → requires_action → processing → succeeded/failed. Requirements: a client retry (double-click, network retry, mobile reconnect) must NEVER charge twice; you must reconcile against the processor's async webhook as source of truth; and an in-flight timeout to the processor must not leave money in limbo. Strong consistency on the intent's terminal state is mandatory.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts — data model, bottlenecks, consistency, failure modes — and name the trade-offs you are making.