Design a Three-Day Donation Campaign with Third-Party Payments

Design a donation system for a campaign intended to process \$100 million over three days. Payments are handled by a third-party provider. Cover donation submission, payment processing, timely acknowledgement, and scale and correctness during the fixed event window. ### Constraints & Assumptions - The campaign has a three-day duration and a stated monetary total. - Payment processing is external. - Monetary volume alone does not determine request rate; ask about donation size and traffic bursts. - Distinguish acknowledging receipt of a request from confirming a successful payment. ### Clarifying Questions to Ask - Is the total a target or a hard cap, and what happens to in-flight requests at the deadline? - What burst traffic and typical donation amounts should the system support? - Which provider idempotency, notification, and status-query capabilities are available? ### Part 1 — Accept and Confirm Donations Trace the durable records and provider calls, including duplicate requests and ambiguous responses. #### What This Part Should Cover - Stable donation identity and request-key binding. - Accepted, pending, confirmed, failed, and indeterminate states. - Provider reconciliation and accurate user acknowledgement. ### Part 2 — Handle Campaign Load and Closure Explain capacity, overload, progress totals, and the end-of-campaign boundary. #### What This Part Should Cover - Traffic assumptions and provider bottlenecks. - Durable buffering and backpressure. - Correct totals and explicit treatment of pending donations at closure. ```hint A real-time success message must not be based only on successfully putting a payment request into a queue. ``` ### What a Strong Answer Covers The design should preserve money-movement correctness under retries and failures while giving donors prompt, truthful status. It should scale from transaction-rate estimates and define the campaign's closing behavior without assuming a target total is a hard limit. ### Follow-up Questions - How would you avoid double-counting repeated provider notifications? - What if the provider is slow during a publicity-driven traffic spike? - How would you reconcile the displayed total after reversals or delayed confirmations?