##### Question Design an online donation platform that lets users discover and contribute to charity campaigns or nonprofit organizations. Payment execution is handled through an **external payment provider/SDK**, but the system must still guarantee that donations are never lost, duplicated, or recorded with the wrong amount. The interviewer is especially interested in how you handle payment failures, retries, duplicate callbacks, partial outages, and sudden traffic spikes during major fundraising events or disasters. Assume: - Millions of registered users. - Donations are processed through an external payment provider; you do not run the card network yourself. - Donation spikes can occur during major campaigns or disasters. - The system must avoid duplicate charges and preserve a reliable audit trail. - Notifications and analytics can be eventually consistent, but payment and ledger correctness are critical. Address the following: 1. Clarify functional and non-functional requirements (correctness, durability, availability, auditability, spike handling). 2. Define the core user-facing and admin/nonprofit **APIs**. 3. Design the **data model** (campaigns, donations, ledger, recurring donations, payouts), storing money as integer cents. 4. Lay out the **high-level architecture** and its components. 5. Walk through the **donation/payment request flow**, including how an external payment SDK or provider is invoked. 6. Explain how you achieve **transaction correctness and idempotency** — preventing duplicate charges, handling retries, double-clicks, and a crash that occurs after charging but before the DB is updated. 7. Describe **reliability and failure handling**: provider timeouts, duplicate/out-of-order webhooks, queue or notification failures, and reconciliation. 8. Support **one-time and recurring donations**, **receipts and donation history** for users, and **payouts plus basic reporting** for nonprofits. 9. Support internal **admins** who can create, approve, pause, and audit campaigns. 10. Describe the **consistency model** (what must be strongly consistent vs. eventually consistent). 11. Explain the **scaling strategy** for read-heavy campaign browsing and write-heavy donation spikes. 12. Cover **security/compliance** (no raw card data, tokenization, webhook signature verification, RBAC, audit logs, fraud detection). 13. Discuss **observability** and the key **tradeoffs**.

A Lyft onsite system design question: design an online donation platform that processes one-time and recurring donations through an external payment provider while guaranteeing no lost, duplicated, or wrong-amount charges. It tests payment-flow correctness, idempotency, append-only ledgers, reconciliation, data modeling, consistency tradeoffs, and scaling for donation spikes.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Lyft.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Lyft during technical interviews.

Design a Donation Platform | Lyft Interview Question

Question

Design an online donation platform that lets users discover and contribute to charity campaigns or nonprofit organizations. Payment execution is handled through an external payment provider/SDK, but the system must still guarantee that donations are never lost, duplicated, or recorded with the wrong amount. The interviewer is especially interested in how you handle payment failures, retries, duplicate callbacks, partial outages, and sudden traffic spikes during major fundraising events or disasters.

Assume:

Millions of registered users.
Donations are processed through an external payment provider; you do not run the card network yourself.
Donation spikes can occur during major campaigns or disasters.
The system must avoid duplicate charges and preserve a reliable audit trail.
Notifications and analytics can be eventually consistent, but payment and ledger correctness are critical.

Address the following:

Clarify functional and non-functional requirements (correctness, durability, availability, auditability, spike handling).
Define the core user-facing and admin/nonprofit APIs .
Design the data model (campaigns, donations, ledger, recurring donations, payouts), storing money as integer cents.
Lay out the high-level architecture and its components.
Walk through the donation/payment request flow , including how an external payment SDK or provider is invoked.
Explain how you achieve transaction correctness and idempotency — preventing duplicate charges, handling retries, double-clicks, and a crash that occurs after charging but before the DB is updated.
Describe reliability and failure handling : provider timeouts, duplicate/out-of-order webhooks, queue or notification failures, and reconciliation.
Support one-time and recurring donations , receipts and donation history for users, and payouts plus basic reporting for nonprofits.
Support internal admins who can create, approve, pause, and audit campaigns.
Describe the consistency model (what must be strongly consistent vs. eventually consistent).
Explain the scaling strategy for read-heavy campaign browsing and write-heavy donation spikes.
Cover security/compliance (no raw card data, tokenization, webhook signature verification, RBAC, audit logs, fraud detection).
Discuss observability and the key tradeoffs .

Question

Assume:

Millions of registered users.
Donations are processed through an external payment provider; you do not run the card network yourself.
Donation spikes can occur during major campaigns or disasters.
The system must avoid duplicate charges and preserve a reliable audit trail.
Notifications and analytics can be eventually consistent, but payment and ledger correctness are critical.

Address the following:

Clarify functional and non-functional requirements (correctness, durability, availability, auditability, spike handling).
Define the core user-facing and admin/nonprofit APIs .
Design the data model (campaigns, donations, ledger, recurring donations, payouts), storing money as integer cents.
Lay out the high-level architecture and its components.
Walk through the donation/payment request flow , including how an external payment SDK or provider is invoked.
Explain how you achieve transaction correctness and idempotency — preventing duplicate charges, handling retries, double-clicks, and a crash that occurs after charging but before the DB is updated.
Describe reliability and failure handling : provider timeouts, duplicate/out-of-order webhooks, queue or notification failures, and reconciliation.
Support one-time and recurring donations , receipts and donation history for users, and payouts plus basic reporting for nonprofits.
Support internal admins who can create, approve, pause, and audit campaigns.
Describe the consistency model (what must be strongly consistent vs. eventually consistent).
Explain the scaling strategy for read-heavy campaign browsing and write-heavy donation spikes.
Cover security/compliance (no raw card data, tokenization, webhook signature verification, RBAC, audit logs, fraud detection).
Discuss observability and the key tradeoffs .

Design a Donation Platform

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP

Design a Donation Platform

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP