Handle a Short Payment Traffic Surge through a Third-Party Processor

Design a payment flow on top of a third-party processor for a short event with high concurrent traffic. Cover idempotency, prevention of duplicate charges, retries with exponential backoff, dead-letter handling, and queues that absorb the surge. Define APIs and data models, estimate QPS, and compare SQL with NoSQL storage. ### Clarifying Questions No attendee count, event duration, processor quota, or completion deadline is supplied. State numerical examples as hypothetical capacity calculations. Clarify the processor's idempotency and status-query guarantees, accepted payment methods, and what users see while processing is pending. ### What a Strong Answer Covers Durable acceptance, one logical payment identity across retries, transactional state changes, queue backpressure, ambiguous processor outcomes, reconciliation, and capacity reasoning tied to the downstream bottleneck. ### Follow-up Questions - What happens if the processor charges successfully but the worker times out before recording success? - Why is moving a payment to a dead-letter queue not equivalent to proving it was never charged?