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 Technical Screen rounds at DoorDash.

What role is this question designed for?

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

Design limited-time donation platform | DoorDash Interview Question

Quick Overview

This question evaluates system-design and distributed-systems competencies, covering large-scale architecture, real-time data pipelines and leaderboards, payment correctness and idempotency, storage partitioning, caching, traffic protection, observability, and failure-recovery planning.

System Design: Donations Platform for a Three-Day Global Fundraising Campaign

Context

You are to design an internet-scale donations platform for a time-bounded, three-day global fundraising campaign. The platform must handle significant traffic spikes during live events, provide real-time visibility into totals and leaderboards, ensure payment correctness, and remain highly available across regions.

Requirements

Design and specify the following:

Functional APIs
- Create donation (intent), confirm payment, refund.
- Query: totals and leaderboards (by campaign, country, team, etc.).
Data model
- Core entities (campaign, donation, payment, refund, donor/PII segregation, ledger), indexes, and unique constraints.
Idempotency and deduplication
- Strategy for client retries and provider webhook retries; prevention of double-submits.
Real-time totals and leaderboards
- Running totals with sub-second updates; unique donors, top teams/countries.
Risk controls
- Fraud checks and deduplication heuristics; velocity limits.
Traffic protection
- Rate limiting, backpressure, and load shedding.
Webhooks
- Handling delayed/out-of-order/duplicated payment provider webhooks and reconciliation.
Scalability and availability
- Design for global traffic spikes; multi-region availability; explicit consistency trade-offs.
Storage and partitioning
- OLTP vs. streaming/warehouse; partitioning, replication, and hot campaign handling.
Caching
- Strategy for campaign config, totals, and leaderboards.
Streaming and analytics
- Near-real-time pipelines for metrics and BI.
Observability
- Metrics, logs, traces, dashboards, and alerting.
Failure scenarios
- Payment provider outage, double-submits, partial failures; recovery and user experience.
Capacity estimates
- Back-of-the-envelope RPS/QPS, storage, throughput; latency budgets.
Rollout and testing
- Phased rollout, load tests, chaos/failure drills, and monitoring gates.

Quick Overview

Context

Requirements

Design and specify the following:

Functional APIs

Create donation (intent), confirm payment, refund.
Query: totals and leaderboards (by campaign, country, team, etc.).

Data model

Core entities (campaign, donation, payment, refund, donor/PII segregation, ledger), indexes, and unique constraints.

Idempotency and deduplication

Strategy for client retries and provider webhook retries; prevention of double-submits.

Real-time totals and leaderboards

Running totals with sub-second updates; unique donors, top teams/countries.

Risk controls

Fraud checks and deduplication heuristics; velocity limits.

Traffic protection

Rate limiting, backpressure, and load shedding.

Webhooks

Handling delayed/out-of-order/duplicated payment provider webhooks and reconciliation.

Scalability and availability

Design for global traffic spikes; multi-region availability; explicit consistency trade-offs.

Storage and partitioning

OLTP vs. streaming/warehouse; partitioning, replication, and hot campaign handling.

Caching

Strategy for campaign config, totals, and leaderboards.

Streaming and analytics

Near-real-time pipelines for metrics and BI.

Observability

Metrics, logs, traces, dashboards, and alerting.

Failure scenarios

Payment provider outage, double-submits, partial failures; recovery and user experience.

Capacity estimates

Back-of-the-envelope RPS/QPS, storage, throughput; latency budgets.

Rollout and testing

Phased rollout, load tests, chaos/failure drills, and monitoring gates.

Design limited-time donation platform

Quick Overview

System Design: Donations Platform for a Three-Day Global Fundraising Campaign

Context

Requirements

Solution

Submit Your Answer to Earn 20XP

Design limited-time donation platform

Quick Overview

System Design: Donations Platform for a Three-Day Global Fundraising Campaign

Context

Requirements

Solution

Submit Your Answer to Earn 20XP