Design a Donation System for a Three-Day Fundraising Campaign
Company: DoorDash
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a system that collects donations during a fundraising campaign that runs for three days. Donors pick a charity, choose an amount and pay. The system records every donation and reports how much has been raised.
The prompt fixes only the domain and the three-day duration. Establish the remaining requirements with the interviewer before designing.
```hint Money moves through someone else
Think about which part of the donation flow you control and which part a payment processor controls. Then ask how the two stay in agreement when a request or a callback is lost.
```
```hint The calendar is a requirement
Ask what a hard three-day window implies: capacity planning before the start, donations still in flight at the end, and work that happens only after the campaign closes.
```
### Constraints and Clarifications
- The campaign has a fixed start and a fixed end, three days apart.
- Assume that card payments go through a third-party payment processor, and that the system never stores card numbers.
### Clarifying Questions
- Who donates: signed-in users of an existing app, anonymous web visitors, or both?
- How many charities take part, and can one donation be split between several of them?
- Is a live running total shown to donors? If so, how fresh must it be?
- What peak traffic should the design handle, for example right after the campaign is promoted?
- Are there minimum or maximum amounts, matching gifts, refunds or tax receipts?
- What happens to a payment that is still being confirmed at the moment the campaign closes?
### What a Strong Answer Covers
- Requirements and a capacity estimate shaped by a short, bursty, time-boxed event
- A payment flow with idempotency, processor callbacks and reconciliation, so no donation is lost or charged twice
- A data model with a donation state machine and uniqueness constraints
- Running totals that do not turn into a write hotspot
- Failure handling for processor outages, lost callbacks and client retries
- Abuse protection and the work that happens after the campaign closes (settlement, payouts, refunds)
### Follow-up Questions
- How would you add a sponsor who matches donations up to a cap?
- The payment processor is down for an hour on day two. What do donors see, and how do you recover?
- How would you show a live leaderboard of charities?
- After the campaign, how do you prove that the reported total matches the money actually received?
Overview: Design a donation system for a fundraising campaign that runs for exactly three days, where donors choose a charity, pay through a payment processor and see running totals. It tests payment idempotency and reconciliation, handling a time-boxed traffic burst, avoiding write hotspots on totals, and fraud protection.