PaymentIntent lifecycle and idempotency
Design a PaymentIntent object that models the full lifecycle of a single payment (created → requires_action → processing → succeeded/failed) and stays correct under aggressive client and network retries. The same client may call `confirm` 5 times because of timeouts, a webhook from the bank may arrive before the synchronous response, and a `cancel` can race a late `authorize`. ~30,000 confirms/sec at peak. Requirement: a given PaymentIntent must never result in two authorizations or a charge after a successful cancel, and every API call must be safely replayable. How do you model the state, transitions, and concurrency control so the object is the single source of truth?
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.