Design a scalable donation system with reliable payment processing
Company: Whatnot
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a donation system: people give money to a cause or fundraiser, the system charges their payment method, records every donation, and shows donors and organizers how much has been raised. The report gives only the name of the problem, and notes that the interviewer kept returning to the same question about how the design scales, so be ready to defend your scaling choices more than once. Settle the scope and scale with the interviewer before designing.
```hint Money moves once
Think about what happens when the payment provider times out and the donor presses the button again.
```
```hint Find the hottest record
Ask which single record receives the most writes when one fundraiser suddenly becomes popular, and whether the page really needs that number to be exact to the second.
```
### Clarifying Questions
- Do donors need accounts, or can guests give? Are donations one-time only, or recurring too?
- Is card processing handled by a third-party payment provider?
- How many donations per second arrive normally and at peak, and is the peak concentrated on one fundraiser, for example during a live event?
- Must the raised total be exact in real time, or may it lag by a few seconds?
- Which money flows are in scope: receipts, refunds, payouts to organizers or charities, several currencies?
- What fraud must be prevented?
### What a Strong Answer Covers
- Functional and non-functional requirements and estimates, separating the read peak from the write peak
- APIs and a data model with donations, a ledger and a display projection of totals
- A payment flow that never charges twice: idempotency keys, a state machine, provider callbacks and reconciliation
- Totals that stay fast and correct when one fundraiser receives most of the donations
- A scaling plan for each component, stated as firm choices with their rationale
- Refunds and payouts, fraud defenses, failure handling and observability
### Follow-up Questions
- One fundraiser suddenly receives most of the site's traffic. What breaks first, and how do you fix it?
- The payment provider charged a donor, but your service crashed before recording it. How do you find and fix the gap?
- How would you support monthly recurring donations?
- How do you issue refunds and keep the organizer's payout correct?
Overview: Design a donation system that charges donors through a payment provider, records every donation exactly once and shows how much each fundraiser has raised. It tests payment idempotency, ledgers, provider callbacks and reconciliation, and how the design keeps scaling when one fundraiser suddenly draws heavy traffic.
Read the full Whatnot Software Engineer interview experience this question came from