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 medium difficulty System Design question, commonly asked during Onsite 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 a donations service with 3-day rolling totals

Q: Design a donations service with 3-day rolling totals

This question evaluates a candidate's competency in designing scalable, low-latency streaming data systems, covering event-time windowing, rolling-window aggregation, idempotency for duplicate events, late/out-of-order handling, and auditability.

Design a service that ingests donations and serves rolling 3-day donation totals.

Requirements

Core features

Ingest donation events:
- Each donation has: donation_id (unique), user_id , campaign_id , amount , currency , created_at (event time).
Query APIs:
- GET /campaigns/{id}/total?window=72h → total donated to that campaign in the last 72 hours (rolling window).
- GET /leaderboard?window=72h&k=100 → top-K campaigns by donated amount in the last 72 hours.

Correctness and scale expectations

Must handle duplicate submissions (retries) safely (idempotency).
Donations may arrive late/out of order (e.g., mobile offline, retries).
Support high write throughput (assume 5k–50k donations/sec) and high read QPS for totals/leaderboard.
Windowing is based on event time ( created_at ), not ingestion time.

Non-functional

Low latency reads (p95 < 200ms for totals and leaderboard).
Strong auditability (ability to reconcile totals from raw events).

Deliverables

High-level architecture
Data model and storage choices
Windowed aggregation approach
Handling idempotency, late events, and consistency
Scaling, caching, and failure modes

Requirements

Core features

Ingest donation events:

Each donation has: donation_id (unique), user_id , campaign_id , amount , currency , created_at (event time).

Query APIs:

GET /campaigns/{id}/total?window=72h → total donated to that campaign in the last 72 hours (rolling window).
GET /leaderboard?window=72h&k=100 → top-K campaigns by donated amount in the last 72 hours.

Correctness and scale expectations

Must handle duplicate submissions (retries) safely (idempotency).

Donations may arrive late/out of order (e.g., mobile offline, retries).

Support high write throughput (assume 5k–50k donations/sec) and high read QPS for totals/leaderboard.

Windowing is based on event time ( created_at ), not ingestion time.

Non-functional

Low latency reads (p95 < 200ms for totals and leaderboard).

Strong auditability (ability to reconcile totals from raw events).

Design a donations service with 3-day rolling totals

Quick Overview

Requirements

Core features

Correctness and scale expectations

Non-functional

Deliverables

Solution

Submit Your Answer to Earn 20XP

Design a donations service with 3-day rolling totals

Quick Overview

Requirements

Core features

Correctness and scale expectations

Non-functional

Deliverables

Solution

Submit Your Answer to Earn 20XP