Design a Crowdfunding Platform

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up. Card payments themselves are designed in Design a Payment Processing System; this page links there instead of re-teaching them, and does the same for the other loops it builds on.

Loop Opener: What Is Crowdfunding?

You Already Know One: a Pre-Order With a Promise

A creator says: "I'll make 1,000 copies of this board game if at least $50,000 is pledged by March 31." People who want the game pledge: they promise to pay, usually in exchange for a reward such as a copy of the game. If $50,000 or more is pledged by the deadline, every backer is charged and the creator gets the money to make the game. If not, nobody pays anything, and the creator gets nothing. That rule is called all-or-nothing.

It's a pre-order with a condition attached. The best-known example is Kickstarter. As of 2026-09-28, its help center says that when a campaign misses its goal "no money changes hands" (article "Why is funding all-or-nothing?"), and its blog says a backer's card "will be charged when the project reaches its funding deadline" ("When is My Card Charged?", 17 May 2024).

Synthesizing vector architecture diagram...

The whole product in one picture. Weeks of promises on the left, one decision in the middle, and money that moves only on the right, after the deadline.

What Makes It Hard

1. Money moves at one instant, weeks after the promise. A card can't simply be held for a month: card authorizations expire long before a campaign ends. We need a different way to be sure we can charge later.
2. The first minute and the last minute. A hit campaign gets thousands of pledges a second when it launches. When it ends, a million charges must each happen exactly once, as fast as the payment provider allows.
3. Limited perks. 500 Early Bird slots, 20,000 people who want one.
4. Books that must close. Pledged, charged, failed, refunded, fees, paid out: every cent has to be accounted for, long after the campaign ended.

The Question the Whole Loop Answers

How do we collect millions of promises safely, and then, at one instant, turn each one into exactly one charge, or release it, for every campaign on the platform?

The answer gets sharper every round:

• Round 1: pledges are saved payment methods plus a ledger of promises; a fence closes pledging at the deadline; settlement charges each pledge with a per-attempt idempotency key.
• Round 2: a hot campaign that never locks one row, tiers that never oversell under a flash crowd, settlement as a rate-limited, resumable saga, failed-card recovery, and a money ledger with fees, payouts and refunds.
• Round 3: currencies, fraud, moderation, regions, and disputes that arrive months after the money left.

---

Round 1 · Mid-level · "Crowdfunding for One Creative Community"

~35 min · SDE II (L5) · 1 region, 3 AZs · 25,000 pledges/day, ~20 pledges/s at a launch peak · 99.9% · never charge an unfunded campaign, never charge twice, never oversell a tier

R1.1 Establish Design Scope

The interviewer says: "We run a community for board-game and gadget makers. Design the crowdfunding site: creators launch campaigns, backers pledge." Before we draw anything, we ask questions, and we say out loud what each answer changes.

Out of scope for this round:

• Fees and payouts. We record what was collected; paying creators comes in Round 2.
• Multiple currencies, fraud, moderation. Round 3.
• Taxes on rewards, shipping and fulfilment. The creator's job, outside our system.
• Pledges after the deadline. Never.

R1.2 Functional Requirements, Derived Step by Step

Not yet: flash crowds, failed-card recovery, fees and payouts, refunds after charging, currencies.

R1.3 Non-Functional Requirements: the Questions

Numbers come in R1.7. For now, the invariants in plain words, most important first:

• Nobody is charged for an unfunded campaign. A charge that should never have happened costs a refund, the fee we don't get back, and the backer's trust.
• Each pledge of a funded campaign is charged at most once. Retries, crashes and duplicate webhooks must never produce a second charge.
• A limited tier never sells more than its limit. The creator promised 500 Early Bird copies, not 504.
• No pledge is accepted after the deadline, and no pledge that was accepted is left out of the funded decision.
• Pledging feels instant. Backers click and see "You're a backer" in well under a second.
• Auditability. Months later, we can explain every change to every total.
• Availability. If pledging is down during a campaign's last hours, the creator can miss their goal because of us.

R1.4 The API

Create and publish a campaign. Amounts are integers in the currency's minor unit (cents), never floats.

httpCopy
POST /v1/campaigns HTTP/1.1
Authorization: Bearer <creator token>
Idempotency-Key: 3f1c9a2e-7b44-4d0e-9a51-6c2f8e1d0b77
Content-Type: application/json

{
  "title": "Harbor Lights: a cooperative lighthouse game",
  "goal_minor": 5000000,
  "currency": "USD",
  "deadline": "2027-03-31T23:59:00-04:00",
  "tiers": [
    { "title": "Early Bird", "min_pledge_minor": 4900, "limit": 500 },
    { "title": "Standard copy", "min_pledge_minor": 5900, "limit": null }
  ]
}

It returns 201 with "campaign_id": "cmp_01JF3KQ8" and "status": "DRAFT". POST /v1/campaigns/cmp_01JF3KQ8/publish moves it to LIVE. The deadline is stored as an absolute instant (2027-04-01T03:59:00Z); the creator's time zone is only for display.

Read a campaign.

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json

{
  "campaign_id": "cmp_01JF3KQ8",
  "status": "LIVE",
  "goal_minor": 5000000,
  "pledged_minor": 3712400,
  "backers": 612,
  "deadline": "2027-04-01T03:59:00Z",
  "tiers": [
    { "tier_id": "tir_eb", "title": "Early Bird", "min_pledge_minor": 4900, "remaining": 37 },
    { "tier_id": "tir_std", "title": "Standard copy", "min_pledge_minor": 5900, "remaining": null }
  ]
}

Pledge. The client makes one idempotency key per pledge attempt: a random ID generated once and sent again on every retry of the same attempt, so the server recognizes the retry.

httpCopy
POST /v1/campaigns/cmp_01JF3KQ8/pledges HTTP/1.1
Authorization: Bearer <backer token>
Idempotency-Key: 8b0e5d7c-1a2f-4e93-b6c4-5d9f0a7e3c21
Content-Type: application/json

{ "amount_minor": 6000, "tier_id": "tir_eb", "payment_method_id": null }

A backer with no saved card gets a pledge that is waiting for one:

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{
  "pledge_id": "plg_01JF4B2M",
  "status": "PENDING_SETUP",
  "hold_expires_at": "2027-03-02T15:00:00Z",
  "setup": { "provider": "psp", "client_secret": "seti_..._secret_..." }
}

The browser hands client_secret to the PSP's card form. The card goes from the browser straight to the PSP, which saves it; the PSP's webhook (or the page's return call) then moves the pledge to ACTIVE. A backer who already has a saved card sends its reference in payment_method_id and gets "status": "ACTIVE" at once. A pledge left in PENDING_SETUP for 15 minutes expires and gives its tier slot back (step 1.4).

Change and cancel. PATCH /v1/pledges/plg_01JF4B2M with { "amount_minor": 10000, "tier_id": "tir_std" } changes the amount or tier; DELETE /v1/pledges/plg_01JF4B2M cancels. Both carry idempotency keys, both return 409 campaign_closed after the deadline.

The deadline is half-open. A pledge is accepted only while now() < deadline, checked by the database's clock inside the pledge's own transaction, never by an app server's clock read earlier. At exactly 03:59:00.000Z pledging is over. Step 1.5 shows why this check alone is not the whole story.

Recap

• Pledging is two steps for a new card: create the pledge, then save the card with the PSP.
• Every call that changes something carries an idempotency key.
• The total a page shows is not the thing we decide on; the ledger is (step 1.3).
• Correctness first: no charge without funding, no double charge, no oversold tier, no pledge after the deadline.

Let's build it, starting with the simplest thing that works.

R1.5 Design Evolution: From "Charge on Click" to a Promise Ledger

Every step below follows the same pattern: a problem, your turn to think, the answer, and what the answer costs us. The cost is always the next problem.

Step 1.0: The Baseline

A pledge charges the card immediately and adds the amount to the campaign's total:

sqlCopy
-- On "Pledge": charge the card at the PSP first, then:
UPDATE campaigns SET raised_minor = raised_minor + $amount WHERE campaign_id = $1;
INSERT INTO pledges (campaign_id, backer_id, amount_minor, psp_charge_id) VALUES (...);

Synthesizing vector architecture diagram...

What's good about it: it's how a shop works, and it's two lines.

What it costs us: it ignores the one rule that makes this product crowdfunding. If the goal isn't reached, every backer was charged for nothing. The next steps fix that first, then the races underneath.

Step 1.1: Where Is the Money for 30 Days?

Synthesizing vector architecture diagram...

The card goes from the browser to the PSP; we only ever see references. Nothing is charged, and the pledge counts toward the total only once the card is saved.

Step 1.2: The Backer Double-Clicked and Has Two Pledges

sqlCopy
CREATE UNIQUE INDEX one_live_pledge_per_backer
    ON pledges (campaign_id, backer_id)
    WHERE status IN ('PENDING_SETUP', 'ACTIVE');

Loop primitive: Idempotency & Effectively-Once Processing

Step 1.3: The Total on the Page Doesn't Match the Pledges

The ledger is append-only by construction, not by convention:

sqlCopy
CREATE TABLE pledge_ledger (
    entry_id     BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    campaign_id  BIGINT      NOT NULL,
    pledge_id    BIGINT      NOT NULL,
    request_id   BIGINT      NOT NULL,        -- the pledge_requests row that caused it
    delta_minor  BIGINT      NOT NULL,
    kind         TEXT        NOT NULL CHECK (kind IN ('ACTIVATE','CHANGE','CANCEL')),
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
    UNIQUE (request_id, kind),               -- a replayed request can't add a second entry
    CHECK ((kind = 'ACTIVATE' AND delta_minor > 0) OR (kind = 'CANCEL' AND delta_minor < 0) OR kind = 'CHANGE')
);
CREATE INDEX pledge_ledger_by_campaign ON pledge_ledger (campaign_id) INCLUDE (delta_minor);
-- The service's role gets INSERT and SELECT only; a trigger also rejects UPDATE and DELETE.
REVOKE UPDATE, DELETE ON pledge_ledger FROM pledge_service;

Related loops: the outbox and event-driven ledger loop (step 2.6, an auditable ledger) and the payment loop (step 1.5, double entry).

Step 1.4: The 500-Slot Early Bird Tier Sold 504

sqlCopy
CREATE TABLE reward_tiers (
    tier_id           BIGINT PRIMARY KEY,
    campaign_id       BIGINT NOT NULL REFERENCES campaigns(campaign_id),
    title             TEXT   NOT NULL,
    min_pledge_minor  BIGINT NOT NULL CHECK (min_pledge_minor > 0),
    limit_qty         INT    CHECK (limit_qty > 0),          -- NULL: unlimited, no counting
    claimed           INT    NOT NULL DEFAULT 0 CHECK (claimed >= 0),
    held              INT    NOT NULL DEFAULT 0 CHECK (held >= 0),
    CONSTRAINT never_oversell CHECK (limit_qty IS NULL OR claimed + held <= limit_qty)
);

-- Card saved in time: the hold becomes a claim.
UPDATE reward_tiers SET held = held - 1, claimed = claimed + 1
WHERE tier_id = $1;                                   -- only after the pledge's own
                                                      -- PENDING_SETUP -> ACTIVE update changed 1 row
-- Card saved after the sweeper expired the hold: try to re-claim.
UPDATE reward_tiers SET claimed = claimed + 1
WHERE tier_id = $1 AND claimed + held + 1 <= limit_qty;   -- 0 rows: ask the backer to choose again

Primitive: Database Isolation Levels, ACID and Concurrency Anomalies

Drill: The on-call doctor anomaly (why snapshot isolation allows write skew is the "count, then insert" answer above; why not Serializable everywhere is the answer below it)

Step 1.5: A Pledge Arrived After the Deadline, and Another Committed After We Added Up the Total

sqlCopy
-- Inside every pledge-activation, change or cancel transaction (Read Committed):
UPDATE campaigns
SET pledged_minor = pledged_minor + $delta, backers = backers + $backer_delta
WHERE campaign_id = $1 AND status = 'LIVE' AND now() < deadline;
-- 0 rows: ROLLBACK and answer 409 campaign_closed.

-- The close job, once now() >= deadline:
UPDATE campaigns SET status = 'ENDED', ended_at = now()
WHERE campaign_id = $1 AND status = 'LIVE' AND deadline <= now();
-- Waits for in-flight pledges' row locks. 1 row: we closed it. 0 rows: another job instance did.

Synthesizing vector architecture diagram...

Pledge A started before the deadline and committed after it, and it's still counted, because the close waited for it. Pledge B arrived after the close and was refused. Nothing slips between.

Loop primitive: Leases, Fencing Tokens & Distributed Locks (a fence is whatever makes a late writer's write fail where the data lives; here, a row lock and a status the late writer must re-read)

Step 1.6: The Deadline Passed. Who Settles, and How Do We Charge 250 Backers Exactly Once Each?

Synthesizing vector architecture diagram...

Round 1's campaign lifecycle. Every arrow is one conditional update on the current status. Round 2 adds what happens after SETTLED (collection, reconciliation, payout); Round 3 adds review and suspension.

Synthesizing vector architecture diagram...

Round 1's pledge lifecycle. Only ACTIVE pledges count toward the total. A timeout leaves the pledge in CHARGING with an attempt the resolver asks the PSP about; it never moves on by guesswork.

The charge attempt, with its guard:

sqlCopy
CREATE TABLE charge_attempts (
    pledge_id        BIGINT      NOT NULL,
    attempt_no       SMALLINT    NOT NULL,
    psp_key          TEXT        NOT NULL UNIQUE,     -- 'plg_01JF4B2M:charge:1'
    status           TEXT        NOT NULL CHECK (status IN ('IN_FLIGHT','SUCCEEDED','FAILED')),
    psp_payment_id   TEXT,                            -- stored as soon as the PSP answers
    decline_code     TEXT,
    created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    PRIMARY KEY (pledge_id, attempt_no)
);
CREATE UNIQUE INDEX one_success_per_pledge ON charge_attempts (pledge_id) WHERE status = 'SUCCEEDED';

-- Start attempt n, in one short transaction, before calling the PSP:
UPDATE pledges SET status = 'CHARGING', charge_attempt = charge_attempt + 1
WHERE pledge_id = $1 AND status = 'TO_CHARGE'
RETURNING charge_attempt;                             -- 0 rows: someone else has it
INSERT INTO charge_attempts (pledge_id, attempt_no, psp_key, status)
VALUES ($1, $n, $pledge_public_id || ':charge:' || $n, 'IN_FLIGHT');

Primitive: Two-Phase Commit and Saga Orchestration

Drill: The GC pause that corrupted shared storage (why an expiring lease doesn't protect the charge is point 5; the conditional state change on the pledge is exactly "optimistic concurrency at the database instead of a lock")

Round 1 Step Summary

R1.6 Architecture v1

Now the concepts get AWS names.

Synthesizing vector architecture diagram...

One writer holds every invariant: the tier counters, the ledger, the campaign's status. The PSP is reached for card setup at pledge time and for charges only after the deadline. Emails never run inside a money transaction; they go through the outbox.

The pieces:

• Campaign and pledge service: one stateless container on ECS Fargate (containers without managing servers), three tasks, one per AZ. It serves the API, receives PSP webhooks, and runs the tier-hold sweeper.
• Aurora PostgreSQL: one writer and one replica in another AZ that Aurora promotes if the writer fails. Everything that decides anything is on the writer.
• Close job and settlement workers: two Fargate tasks. The close job polls every 30 seconds for due campaigns; workers claim settlement jobs with SKIP LOCKED.
• Outbox relay → SQS → notification worker → SES. Events ("pledge confirmed", "campaign funded", "you were charged") are written to an outbox table in the same transaction as the state change, relayed to SQS, and sent by a worker through Amazon SES. The outbox pattern and its relay are the outbox loop's steps 1.1 to 1.3. A new SES account starts in the sandbox: "a maximum of 200 messages per 24-hour period" and "1 message per second" (docs.aws.amazon.com/ses, request-production-access), and quotas are "separate for each AWS Region". We request production access before launch.
• Secrets: the PSP's API key and webhook signing secret live in AWS Secrets Manager.

Scheduler per deadline, or a poll? Amazon EventBridge Scheduler can fire a one-time schedule at an exact time ("A one-time schedule will invoke a target only once", docs.aws.amazon.com/scheduler), and its default quota is 10,000,000 schedules per Region, adjustable. One schedule per deadline would be precise to the minute. We choose the poll for Round 1: every 30 seconds, WHERE status = 'LIVE' AND deadline <= now(), on a partial index. It's one query, it can't miss a campaign whose schedule failed to be created or wasn't updated when the creator changed the deadline, and 30 seconds of delay is invisible next to a 30-day campaign. Correctness never depended on the trigger anyway: the fence and the status updates do.

The tables (the tier table is in step 1.4, the ledger in step 1.3, the attempts in step 1.6):

sqlCopy
CREATE TABLE campaigns (
    campaign_id    BIGINT PRIMARY KEY,
    public_id      TEXT        NOT NULL UNIQUE,        -- 'cmp_01JF3KQ8'
    creator_id     BIGINT      NOT NULL,
    goal_minor     BIGINT      NOT NULL CHECK (goal_minor > 0),
    currency       CHAR(3)     NOT NULL,
    deadline       TIMESTAMPTZ NOT NULL,
    status         TEXT        NOT NULL CHECK (status IN ('DRAFT','LIVE','CANCELLED','ENDED',
                                   'FUNDED','SETTLING','SETTLED','UNSUCCESSFUL','RELEASED')),
    pledged_minor  BIGINT      NOT NULL DEFAULT 0,     -- snapshot of the ledger sum (step 1.3)
    backers        INT         NOT NULL DEFAULT 0,
    final_minor    BIGINT,                             -- exact sum after the fence
    ended_at       TIMESTAMPTZ,
    published_at   TIMESTAMPTZ
);
CREATE INDEX campaigns_due ON campaigns (deadline) WHERE status = 'LIVE';

CREATE TABLE pledges (
    pledge_id          BIGINT PRIMARY KEY,
    public_id          TEXT        NOT NULL UNIQUE,    -- 'plg_01JF4B2M'
    campaign_id        BIGINT      NOT NULL REFERENCES campaigns(campaign_id),
    backer_id          BIGINT      NOT NULL,
    tier_id            BIGINT,                         -- NULL: no reward
    amount_minor       BIGINT      NOT NULL CHECK (amount_minor > 0),
    status             TEXT        NOT NULL CHECK (status IN ('PENDING_SETUP','ACTIVE','EXPIRED',
                           'CANCELLED','RELEASED','TO_CHARGE','CHARGING','CHARGED','FAILED')),
    psp_customer_id    TEXT        NOT NULL,           -- the backer at the PSP
    psp_setup_id       TEXT,                           -- the SetupIntent, if a new card
    psp_payment_method TEXT,                           -- set when the card is saved
    hold_expires_at    TIMESTAMPTZ,                    -- only while PENDING_SETUP with a limited tier
    charge_attempt     SMALLINT    NOT NULL DEFAULT 0,
    created_at         TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX pledges_hold_due ON pledges (hold_expires_at) WHERE status = 'PENDING_SETUP';
CREATE INDEX pledges_to_charge ON pledges (campaign_id, pledge_id) WHERE status = 'TO_CHARGE';

CREATE TABLE pledge_requests (                         -- idempotency keys and stored replies
    backer_id        BIGINT NOT NULL,
    idempotency_key  TEXT   NOT NULL,
    request_hash     BYTEA  NOT NULL,
    response         JSONB  NOT NULL,
    created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    request_id       BIGINT GENERATED ALWAYS AS IDENTITY UNIQUE,
    PRIMARY KEY (backer_id, idempotency_key)
);

CREATE TABLE settlement_jobs (
    campaign_id   BIGINT PRIMARY KEY,
    kind          TEXT   NOT NULL CHECK (kind IN ('CHARGE','RELEASE')),
    lease_owner   TEXT,
    lease_until   TIMESTAMPTZ,
    done          BOOLEAN NOT NULL DEFAULT false
);

CREATE TABLE webhook_inbox (                           -- dedupe PSP events by their ID
    event_id     TEXT PRIMARY KEY,
    received_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

Synthesizing vector architecture diagram...

A pledge has many ledger entries (activate, change, cancel) and, if funded, one or more numbered charge attempts, at most one of them successful.

Trace 1: a new backer pledges for a limited tier. The sequence in step 1.1: one transaction writes the pledge PENDING_SETUP and held + 1 on Early Bird (stored with its idempotency key); the service creates a SetupIntent and returns its client secret; the backer types the card into the PSP's form; the setup_intent.succeeded webhook arrives, is deduplicated in the inbox, and one transaction moves the pledge to ACTIVE, moves the slot from held to claimed, appends ACTIVATE +6000 to the ledger and adds 6,000 to the campaign's snapshot, conditional on the campaign still being LIVE before its deadline.

Trace 2: a pledge after the deadline. At 03:59:00.3 a backer clicks Pledge on a saved card. The pledge transaction's conditional update on the campaign row waits behind the close job's update (step 1.5's diagram), re-reads ENDED, changes 0 rows and rolls back: 409 campaign_closed, and no ledger entry, no tier change, nothing to undo.

Trace 3: a funded campaign settles.

Synthesizing vector architecture diagram...

Each pledge is its own small transaction on each side of one PSP call. A crash anywhere leaves at most one pledge in CHARGING, which the next worker resolves by re-sending the same key.

Trace 4: an unsuccessful campaign. The exact sum is $41,300 against a $50,000 goal. One transaction moves the campaign to UNSUCCESSFUL, all ACTIVE pledges to RELEASED, and writes an outbox event; the notification worker tells 250 backers "not funded, you weren't charged". The campaign moves to RELEASED. The PSP is not called at all.

R1.7 Numbers

Pledges. From the interviewer's numbers plus our assumptions:

$$\frac{3{,}000 \text{ live campaigns} \times 250 \text{ backers}}{30 \text{ days}} = 25{,}000 \text{ pledges/day} \approx 0.29 \text{ pledges/s}$$

The average is useless here. Pledges bunch at launches and deadlines. We assume the community's most popular creator launches to a big mailing list and gets 1,200 pledges in the first minute: $1{,}200 / 60 = 20$ pledges a second on one campaign, about 70 times the whole platform's average. That's the rate we design for.

Campaigns ending. $3{,}000 / 30 = 100$ campaigns end a day. We assume 60% are funded (an assumption, not an industry figure):

• Funded: $60 \times 250 = 15{,}000$ charges a day.
• Unsuccessful: $40 \times 250 = 10{,}000$ pledges released a day, with no PSP calls.
• Creators like round deadlines, so we assume a quarter of the day's deadlines fall in one hour: 25 campaigns, 15 funded, $15 \times 250 = 3{,}750$ charges. Our workers charge at 10 a second (our choice, far below the PSP's limit): $3{,}750 / 10 = 375$ s, about 6 minutes.

PSP calls against the PSP's limits. Stripe documents live-mode limits of "100 requests per second" per account and "25 requests per second" for individual API endpoints unless noted (docs.stripe.com/rate-limits, checked 2026-09-28). We assume 40% of pledges come from backers without a saved card, so each needs a SetupIntent: $25{,}000 \times 0.4 = 10{,}000$ a day, and at the launch peak $20 \times 0.4 = 8$ a second. Settlement adds 10 charges a second at worst. Both are well under 25 a second per endpoint and 100 a second overall. In Round 1 the PSP's limit is a non-issue; in Round 2 it becomes the constraint.

Ledger and table rows. We assume 10% of pledges are changed once and 5% cancelled: $25{,}000 \times 1.15 = 28{,}750$ ledger entries a day. A ledger entry, from PostgreSQL's row layout (an estimate):

$28{,}750 \times 170 \text{ B} \approx 4.9$ MB a day, about 1.8 GB a year. Pledges (≈ 400 B each with indexes) add 10 MB a day, charge attempts (15,000 a day at ≈ 300 B) 4.5 MB, and idempotency rows (kept 30 days) about 1 GB in steady state. Everything fits in the memory of the smallest instance for years. Size is not our problem; correctness is.

Availability. 99.9% of a 30.4-day month is $43{,}776 \text{ min} \times 0.001 \approx 43.8$ minutes.

Latency. A pledge activation is about five statements on the writer (request row, pledge update, tier update, ledger insert, campaign snapshot update) at about 1 ms each plus a durable commit of a few milliseconds: about 15 ms at the median. The card entry at the PSP takes as long as the backer takes, and isn't ours to measure.

Monthly cost (us-east-1 on-demand prices, 730 hours a month):

Against the money moved. We assume an average pledge of $60: 15{,}000 \times \60 = $900{,}000 collected a day, about \27M a month. At a common card list rate of 2.9% + 30¢ (an assumption; our contract decides), each $60 charge costs $2.04 in PSP fees: about $918K a month. The infrastructure is about 0.003% of the money it moves. And the funding-model choice is worth real money: under charge-now-and-refund, the 10,000 pledges released each day would have been charged and refunded, losing about 10{,}000 \times \2.04 = $20{,}400 a day in fees, about \612K a month, about 690 times this whole platform's infrastructure bill.

R1.8 Trade-Offs

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Says "a pledge is a promise, not a payment", and compares the three funding models with what each costs, including why authorizations don't last.
• Uses idempotency keys plus a business-level unique rule (one live pledge per backer per campaign).
• Keeps an append-only ledger of promises and derives the total from it.
• Protects a limited tier with a counter row, a conditional update and a check constraint, and names write skew in "count, then insert".
• Closes pledging with a fence that waits for in-flight pledges, not with a timestamp comparison.
• Charges each pledge with a (pledge, attempt) key, retries the same attempt with the same key, and allows one success per pledge.

Follow-up questions

1. "Why not keep the pledge as a PaymentIntent at the PSP and let the PSP be our database?" Answer: the PSP knows about cards and charges, not about goals, tiers, deadlines or who changed their pledge from $60 to $100 on day 12. The funded decision needs an exact sum under our own fence. We store the PSP's references on our pledges and treat the PSP as the truth for one thing only: whether money moved.

2. "A backer's card was saved at 15:02, but their Early Bird hold expired at 15:00. What happens?" Answer: the activation tries to re-claim a slot with the same conditional update. If one is free, the pledge activates normally. If not, the backer is asked to choose another tier or no reward. Unlike the hotel loop's version of this race, nothing was charged, so there's nothing to refund.

3. "Can a backer cancel one minute before the deadline and sink the campaign?" Answer: in this design, yes: cancels are allowed until the deadline. That's a real complaint from creators, and it has a known fix: a rule that in the last 24 hours a backer can't cancel or lower a pledge if it would drop the campaign below its goal. It hides a write-skew trap of its own. Round 2's step 2.1 builds it.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "A Hit Campaign, a Million Backers, and Settlement Day"

~40 min · Senior SDE (L6) · 1 region, 3 AZs · 500,000 pledges/day, 3,000 pledges/s on one campaign · a 1M-pledge settlement · pledge P99 < 200 ms · 99.99%

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "We built all-or-nothing crowdfunding for one community: 3,000 live campaigns, 25,000 pledges a day, a launch peak of about 20 a second, and about 100 campaigns ending a day. A pledge is a promise, not a payment: the PSP saves the backer's card with a SetupIntent, and we charge it off-session only if the campaign is funded, because card authorizations last about 7 days and campaigns run 30 to 60. Idempotency keys stop retries, and a partial unique index allows one live pledge per backer per campaign. Every change is an entry in an append-only pledge ledger, with a snapshot total on the campaign row updated in the same transaction. Limited tiers are counter rows with a conditional update and a check constraint; a new card holds a slot for 15 minutes. Pledging closes with a fence: every pledge updates the campaign row conditionally on LIVE and now() < deadline, so the close job's status update waits for in-flight pledges, and only then do we sum the ledger. Settlement charges each pledge with a key per (pledge, attempt), one success per pledge, webhooks through an inbox. One Aurora writer, a few Fargate tasks, about $885 a month. Open costs: every pledge writes one campaign row, a tier row is contended when it opens, settlement is a simple loop, and failed cards just fail."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: the writer owns every invariant, the PSP saves cards at pledge time and charges them only after the deadline.

Round 1 step summary

Open costs: the campaign row is written by every pledge; tier rows at opening; settlement with no rate plan; no recovery for failed cards; no fees, payouts or refunds.

R2.1 The Scope Raise

Interviewer: "The community site grew into a national platform: about 30,000 live campaigns and half a million pledges a day. Next month a famous designer launches at 10:00. Last time they launched, the first minute saw about 3,000 pledges a second on that one campaign, and the 1,000 Early Bird slots went in seconds. That campaign will end in 30 days with about a million backers, all to be charged, and the creator wants their money soon after. Many campaigns end at the same hour, because creators pick round-number deadlines. Backers try to cancel in the final minutes, and creators complain they were sunk at the last moment. A few percent of cards fail at the deadline. We now take a fee and pay creators out, and we sometimes refund backers. And we must survive losing an AZ in the middle of settlement."

We ask back before fixing anything.

Two of those answers are Kickstarter's documented policies, which we adopt as our own. Kickstarter's help center (article "What happens when there is a problem with one of my backer's pledges?", checked 2026-09-28) says: "Backers with errored pledges will have 7 days from the project's deadline to update their payment method. At the end of this period, we'll automatically try to collect their pledge again. If this attempt fails, the backer will be dropped from the campaign." And its blog ("The Simple Steps to Cancel Your Kickstarter Pledge", Kickstarter Staff, 21 Mar 2024) says: "It is not possible to decrease or cancel a pledge during the last 24 hours of the campaign if doing so would drop the project below its funding goal."

Scope change

The "Not yet" list from R1.2 comes back: flash crowds, failed-card recovery, fees, payouts and refunds are now in scope. Currencies are still out.

R2.2 What Breaks in the Round 1 Design

The order we fix it in: the hot row and the closing fence (2.1), hot tiers and the PSP budget at launch (2.2), settlement at scale (2.3), failed charges (2.4), webhooks and reconciliation (2.5), money, fees and payouts (2.6), notifications (2.7).

R2.3 New Requirements and API Additions

The pledge response no longer waits for the total. A pledge is exact and durable when 201 returns; the campaign's displayed total catches up within seconds. The backer's own pages ("You back this campaign: $60, Early Bird") read their own pledge from the writer, so they always see their own write (loop primitive Replication, Quorums & Read-Your-Writes).

Campaign totals, labeled.

jsonCopy
{ "campaign_id": "cmp_09HZ", "pledged_minor": 4130927400, "backers": 688211,
  "as_of": "2027-05-02T10:14:03Z", "exact": false,
  "tiers": [ { "tier_id": "tir_eb", "remaining": 0 }, { "tier_id": "tir_std", "remaining": null } ] }

After the deadline the same call returns "exact": true and the fenced final_minor.

Settlement status, per campaign.

jsonCopy
{ "campaign_id": "cmp_09HZ", "status": "SETTLING",
  "charged": 412000, "failed": 9310, "remaining": 578690, "unknown": 12,
  "rate_per_s": 250, "eta": "2027-06-01T05:02:00Z" }

Fix your payment (a backer in dunning): POST /v1/pledges/{id}/payment-method with a new saved-card reference, or POST /v1/pledges/{id}/confirm which returns the declined payment's client secret when the bank asked for authentication (step 2.4).

Creators' money. GET /v1/creators/{id}/verification returns the PSP's verification status; POST /v1/campaigns/{id}/publish returns 409 creator_not_verified until it's complete. GET /v1/campaigns/{id}/balance returns collected, fees, reserve, paid out and the payout date.

Refunds. POST /v1/pledges/{id}/refunds with an Idempotency-Key, an amount and a reason (CREATOR_REQUEST, DUPLICATE, CAMPAIGN_SUSPENDED, SUPPORT), for support staff and creators; backers ask through support.

Money-ledger entry types (step 2.6): CHARGE, PSP_FEE, REFUND, PLATFORM_FEE, FEE_RECHARGE, RESERVE_HOLD, RESERVE_RELEASE, PAYOUT.

R2.4 Design Evolution: The First Minute and the Last Minute

Step 2.1: 3,000 Pledges a Second, and Every One Updates the Same Row

Synthesizing vector architecture diagram...

The pledge path only inserts. The total is recomputed from the ledger and written as an absolute value, so a replayed event can cost a recompute but never a double count.

Synthesizing vector architecture diagram...

The Round 2 fence. It's the same promise as Round 1's ("the sum includes everything accepted") bought with a database-enforced time limit instead of a lock every pledge takes.

Primitives: Change Data Capture and the Outbox Pattern · loop primitive Sharding, Hot Keys & Rebalancing

Drill: The on-call doctor anomaly (the last-minute cancel is the same write skew as step 1.4's "count, then insert"; why not Serializable for everything is in step 1.4)

Step 2.2: 1,000 Early Bird Slots, 20,000 People in the First 10 Seconds

Synthesizing vector architecture diagram...

The database takes both lanes at full speed; only the new-card lane is metered, because only it spends the PSP's budget. Holds are taken before the queue, so the queue's length must stay well inside the hold.

Loop primitive: Retries, Timeouts, Backpressure & Load Shedding (admission before the expensive work, and a client-side token bucket in front of someone else's rate limit)

Step 2.3: The Campaign Ends: a Million Charges, 250 Other Campaigns, and a Rate Limit

Synthesizing vector architecture diagram...

The checkpoint is the pledges' own states. Nothing needs a separate progress counter that could disagree with them.

Primitive: Two-Phase Commit and Saga Orchestration · loop primitives Idempotency & Effectively-Once Processing and Retries, Timeouts, Backpressure & Load Shedding · related loop: Design a Distributed Job Scheduler

Step 2.4: 40,000 Cards Failed at the Deadline

Synthesizing vector architecture diagram...

Round 2's charging lifecycle. Every retry is a new attempt with a new key, and every arrow into CHARGING is a conditional update, so at most one attempt is ever in flight for a pledge.

Step 2.5: Our Records, the PSP's Webhooks and the PSP's Reports Disagree

Step 2.6: Where Do the Fees Go, When Is the Creator Paid, and What About Refunds?

One campaign's money, end to end. "Harbor Lights" collects 1,000 charges of $60. We assume a PSP fee of 2.9% + 30¢ ($2.04 per charge), our 5% platform fee on collected money net of refunds, and one refund before payout.

Check: clearing gets $60,000 in and $60 + $2,997 + $2,040 + $54,903 = $60,000 out, so it's back to zero. The PSP balance holds \57{,}960 - $60 - $49{,}412.70 = $8{,}487.30, which is exactly our fee (\2,997) plus the creator's reserve ($5,490.30). The processing-fee account is back to zero: the fees were charged to the creator. Each row pair balances on its own.

sqlCopy
CREATE TABLE money_entries (
    entry_id     BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    journal_id   BIGINT      NOT NULL,              -- one business event; its entries sum to zero
    account      TEXT        NOT NULL,              -- 'clearing:cmp_09HZ', 'creator_payable:crt_77', 'platform_fee'
    amount_minor BIGINT      NOT NULL,              -- positive debit, negative credit
    currency     CHAR(3)     NOT NULL,
    kind         TEXT        NOT NULL CHECK (kind IN ('CHARGE','PSP_FEE','REFUND','PLATFORM_FEE',
                               'FEE_RECHARGE','RESERVE_HOLD','RESERVE_RELEASE','PAYOUT')),
    source_ref   TEXT        NOT NULL,              -- 'plg_..:charge:2', 'payout:cmp_09HZ'
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
    UNIQUE (source_ref, account, kind)              -- a replayed event can't post twice
);
-- A deferred constraint trigger checks that each journal_id sums to zero at commit; no UPDATE or DELETE.

Step 2.7: A Million Emails at the Deadline

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Follow a pledge down the left: gate, pledge service, one insert-only transaction. Everything that shows a number (totals, remaining slots) is recomputed from the ledger off the change stream. Everything that calls the PSP takes a token from the same buckets first.

The pieces that are new since Round 1:

• CloudFront serves campaign pages. The page's static parts are cached for minutes; the small totals-and-tiers JSON is cached for 2 seconds. That short TTL is on purpose: a total or a "37 left" is wrong within seconds, and at the deadline the status flips to ENDED. Caching those forever would show a live "Pledge" button on a closed campaign. When a hot page's entry expires, CloudFront's request collapsing sends one request per edge location to the origin while the others wait for its response (CloudFront developer guide, "Request and response behavior for custom origins"). If Valkey itself restarts empty, the origin doesn't let every miss recompute totals: concurrent misses in one task share one read (single-flight), a short lock key (SET lock:<campaign> <task> NX PX 2000) lets one task per campaign refill it, and the rest serve "total updating" for a second instead of hitting the database.

Drill: The product page that melted Redis (the cold-cache stampede is the request-collapsing and single-flight answer above; why not cache forever is the 2-second TTL and the status flip at the deadline)

• Waiting room and gate for scheduled launches (step 2.2), scaled up before the launch time.
• Valkey (ElastiCache): display totals, tier remaining counts, and the PSP token buckets. A primary and a replica in two AZs. Nothing in it is a source of truth: totals are recomputed, and a lost token bucket just starts full, which the PSP's own 429s correct.
• Debezium on MSK Connect → MSK, topics keyed by campaign_id, as in the hotel loop's step 2.1. We choose MSK over Kinesis because the Debezium connector writes Kafka natively and we reuse the topics for notifications.
• Aggregator: marks campaigns dirty from the stream and recomputes totals from a replica at most every 2 seconds each.
• Settlement orchestrator, workers, dunning scheduler and resolver: Fargate tasks that scale out before deadline hours and back to a minimum after.
• Webhook endpoint and inbox consumer, reconciliation, payouts.
• Aurora: a db.r6g.4xlarge writer and a replica in another AZ (R2.6 shows why).

Trace 1: a pledge at 3,000 a second. A returning backer, saved card, Standard tier (unlimited). The waiting room admits them; the pledge service runs one transaction: insert the request row, the pledge (ACTIVE) and its ACTIVATE ledger entry, with a plain read of the campaign's status and deadline. No row is shared with other backers. Commit, 201. About 1.5 seconds later the aggregator's next recompute includes it, and within 2 more seconds CloudFront's copy of the totals expires and the page shows it.

Trace 2: an Early Bird sell-out. Slot 1,000 is held at 10:00:04. The tier row's change event reaches the aggregator, which sets remaining = 0 in Valkey; from then on, Early Bird requests get 409 from the pledge service without a database call. At 10:15:07 a new-card backer's hold expires, the sweeper returns the slot, the next recompute sets remaining = 1, and the next person admitted gets it.

Trace 3: a 1M-pledge settlement with a worker crash. Step 2.3's sequence: the close, the 3-second quiesce, the exact sum, the batched move to TO_CHARGE, workers charging at 250 a second through the bucket. At minute 31 one worker's AZ is lost; its lease expires after 60 seconds; the other workers pick up its batches (the pledges that were still TO_CHARGE), and the resolver re-sends the same keys for the 32 pledges that worker left CHARGING (its 32 calls in flight). The PSP replays 31 stored successes and charges one that had never reached it. No backer is charged twice.

Trace 4: a failed card through dunning. Step 2.4's diagram: declined at 00:41 with insufficient_funds; emailed at once; retried on day 1 (declined) and day 3 (succeeded) as attempts 2 and 3 with new keys.

Trace 5: a payout, then a chargeback. The campaign is COLLECTED on day 7, RECONCILED on day 9, and paid out: step 2.6's entries 3 to 5. A dispute arrives four months later; step 3.6 posts it against the reserve.

R2.6 Numbers and Cost

Pledges.

$$\frac{30{,}000 \times 500}{30} = 500{,}000 \text{ pledges/day} \approx 5.8 \text{ pledges/s average} \qquad \text{vs } 3{,}000/\text{s on one campaign}$$

Campaigns ending. $30{,}000 / 30 = 1{,}000$ a day; a quarter in the busiest hour (an assumption): 250. At 60% funded: 600 funded campaigns a day × 500 = 300,000 charges on a normal day, plus a giant campaign's million when one ends.

Database writes at the launch peak. Returning backers (1,800/s): request row + pledge + ledger entry = 3 inserts. New-card backers (1,200/s): request row + pledge = 2 inserts, plus a tier update for those taking a limited tier; their activation later (200/s) is a pledge update, a tier update and a ledger insert. We assume a third of pledges take a limited tier:

$$1{,}800 \times 3 + 1{,}200 \times 2 + 3{,}000 \times \tfrac{1}{3} + 200 \times 3 = 5{,}400 + 2{,}400 + 1{,}000 + 600 = 9{,}400 \text{ row writes/s}$$

The hotel loop plans about 7,500 row writes a second for a db.r6g.2xlarge writer; we take a db.r6g.4xlarge and plan 15,000 (an assumption to load-test), so the launch uses about 63% of it. The tier row itself sees only about one hold per slot plus returns, thanks to the gate.

The PSP call budget. Stripe's documented live defaults are 100 requests a second per account and 25 per endpoint (payouts: "15 create requests per second"). Our design assumes a negotiated account limit of 1,000 a second and 400 per endpoint; the rows below are how we'd spend it at the worst moment, a launch and a big settlement in the same hour:

The 25% left over is room for retries after 429s. At the defaults, one caller alone hits its endpoint's 25 a second first (that's the 11-hour settlement), but as soon as a launch, a settlement and refunds run together, the account-wide 100 a second is the binding limit: four endpoints at 25 each already use all of it.

Settlement time. From step 2.3: 1M ÷ 25/s ≈ 11.1 hours at the default; 1,075,000 ÷ 250/s ≈ 72 minutes in the busiest hour at the assumed limit, small campaigns done in about 5. Each call takes about 0.5 s (an assumption), so 250 a second means $250 \times 0.5 = 125$ calls in flight: four worker tasks with 32 concurrent calls each.

Webhooks. About one event per charge we subscribe to: $1{,}075{,}000 / 4{,}300 \text{ s} \approx 250$ a second during the busiest hour, each one inbox insert plus one conditional update.

Emails per deadline. A million outcome emails at an assumed 1,000/s SES quota: about 17 minutes; the same again as receipts over the settlement hour.

Ledgers and rows. We assume 15% of pledges are changed or cancelled: $500{,}000 \times 1.15 = 575{,}000$ pledge-ledger entries a day at ≈ 170 B (R1.7's row) = 98 MB a day, about 36 GB a year. Pledges: $500{,}000 \times 400 \text{ B} = 200$ MB a day, about 73 GB a year. Charge attempts: about 330,000 a day on average (normal days plus a giant a month) at ≈ 300 B, about 36 GB a year. Money entries: 3 per charge (the charge's two lines, plus its share of splits and payouts, amortized) at ≈ 170 B: $330{,}000 \times 3 \times 170 \text{ B} \approx 168$ MB a day, about 61 GB a year. About 210 GB a year in Aurora, most of it rarely read after a campaign is paid out.

Cache. Totals and tier counts for 30,000 live campaigns: a few MB. The token buckets: a few keys. Valkey is sized for availability, not memory.

Latency budget, pledge P99 (at our load balancer, card entry excluded; dependent steps add):

Availability. 99.99% of a 30.4-day month is $43{,}776 \times 0.0001 \approx 4.4$ minutes.

Monthly cost (us-east-1 on-demand list prices, 730 hours a month):

The biggest line is email, not databases: the system's real volume is people being told what happened.

Against the business. 300,000 charges a day at an assumed $60 is $18M a day, about $540M a month. Our 5% platform fee is about $27M a month; PSP fees at 2.9% + 30¢ are 300{,}000 \times 30 \times \2.04 \approx $18.4$M a month. PSP fees are about 1,400 times the infrastructure. For comparison, Kickstarter's blog describes a 5% platform fee plus payment processing of "roughly 3-5%" ("Kickstarter Fees: A Comprehensive Guide for Creators", 13 Mar 2024); our 5% is an assumption for this design.

R2.7 Trade-Offs

Three ways to show a hot campaign's total, figures rough:

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a senior (L6) answer adds over L5

• Takes the shared row off the pledge path and says which number is allowed to lag and which never is.
• Rebuilds the closing fence without a lock, with a database-enforced transaction limit and a quiesce window.
• Finds the write skew in the last-24-hours cancel rule and serializes only that rare path.
• Treats the PSP's rate limit as the settlement's real bottleneck, derives the hours from it, and meters every caller, pledges included, through one bucket.
• Designs dunning with a new attempt per retry, handles authentication_required on-session, and states the "stays funded" policy with its fraud risk.
• Posts fees, reserves, payouts and refunds as double-entry journals, and pays out only after reconciliation.

Follow-up questions

1. "The PSP won't raise our limit before the big deadline. Now what?" Answer: we tell the creator the honest timeline: at 25 charges a second, about 11 hours for the first pass. We keep round-robin so the other campaigns ending that day aren't held hostage, and we spend the account-wide budget on settlement by pausing non-urgent calls (bulk card detaches, report downloads). The one thing we don't do is exceed the limit and rely on retries.

2. "Why not keep a Serializable transaction for the last-day cancel and skip the advisory lock?" Answer: it would work: Serializable would detect the two cancels' read-write conflict and abort one. But every cancel would have to be ready to retry, and on a campaign with a flurry of last-day cancels the aborts pile up. The advisory lock makes them wait in line for a few milliseconds instead, and it's scoped to the only path that can break the rule.

3. "A backer fixed their card on day 6 while the day-5 retry was still in flight. Can we charge them twice?" Answer: no. The day-5 retry is attempt 3, in CHARGING. The fix-your-payment path can only start attempt 4 from PAYMENT_FAILED, which the pledge isn't in; it waits for attempt 3's result. And the partial unique index allows one successful attempt per pledge, whatever the code does.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "A Global Marketplace: Currencies, Fraud, and Trust"

~45 min · Principal (L7) · 3 home regions, each with a disaster-recovery copy · 150,000 live campaigns · 3M pledges/day · ~20 currencies · pledging up per region · no double charge across a region failure

R3.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 3. If you're starting here, it's everything you need from Round 2.

Round 2 in 60 seconds. "We scaled to a national platform: 30,000 live campaigns, 500,000 pledges a day, 3,000 a second on one campaign at launch, and a million-backer campaign to settle. Pledges only insert; the campaign's total is recomputed from the ledger off the change stream and set as an absolute value, and the funded decision is an exact ledger sum after the close. The close sets ENDED, waits 3 seconds past a 2-second database-enforced transaction timeout, then sums. Last-day cancels and decreases are serialized per campaign to stop write skew. Hot tiers get a sold-out short-circuit and, for big launches, a gate; new cards wait in a lane metered by the PSP's budget. Settlement is a resumable saga paced by a global token bucket, round-robin across campaigns: 11 hours for a million charges at Stripe's default, about 72 minutes at an assumed negotiated 250 a second. Failed cards get 7 days of dunning with a new attempt per retry, and the campaign stays funded after drops. A double-entry money ledger splits clearing into our fee, recharged processing fees and the creator's payable, holds a 10% reserve, and pays out only after reconciliation. About $13.4K a month. Open costs: one currency, no fraud checks, no moderation, one region, and chargebacks that arrive after payout."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: pledges insert, totals are recomputed off the stream, and settlement is paced by the PSP.

Round 2 step summary

Open costs: one currency; no risk or moderation; one region; disputes after payout.

R3.1 The Scope Raise

Interviewer: "We're global now: backers and creators in about 40 countries and 20 currencies. A backer in Japan backs a campaign priced in euros. Scam campaigns appear, and some creators take the money and disappear. Some campaigns get pushed over their goal by fake backers, and small pledges are being used to test stolen cards. Regulators and the card networks expect us to act on reports quickly. Sometimes we must suspend a campaign, live or already funded, and refund every backer. Chargebacks arrive months later, often because rewards never shipped, after the creator was paid. We'll run in three home regions, and a region can fail during a settlement. And creators want our campaign events in their own tools."

We ask back before fixing anything.

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

Currency on the pledge. The campaign page and the pledge carry the campaign's currency and an estimate in the backer's:

jsonCopy
{
  "pledge_id": "plg_02K1XZ", "amount_minor": 6000, "currency": "EUR",
  "estimate": { "currency": "JPY", "amount_minor": 9780, "rate": "163.00",
                "as_of": "2027-09-02T08:00:00Z", "binding": false }
}

Risk. Every pledge and every creator carries a risk score and the signals behind it (internal API only). A campaign can be in UNDER_REVIEW after its deadline.

Moderation. GET /v1/moderation/cases/{id} with states PENDING → APPROVED | REJECTED; POST /v1/campaigns/{id}/reports for anyone to report a live campaign; POST /v1/campaigns/{id}/suspend for trust and safety, with a reason and an appeal deadline.

Outbound webhooks for creators. Creators register HTTPS URLs; we send pledge.created, campaign.funded, settlement.progress and payout.sent, each signed with an HMAC over the timestamp and the raw body, retried with backoff, and deduplicated by event ID on their side. The sender resolves the URL's address itself and refuses private, loopback and link-local ranges (including the instance metadata address) after every DNS resolution and redirect, so a creator's URL can never reach our internal network (SSRF, server-side request forgery).

Home region. Every campaign has a home_region attribute, fixed at creation from the creator's country, and its public ID carries a region prefix so any region can route to it without a lookup.

R3.4 Design Evolution: Money, Trust and Regions

Step 3.1: A Backer Pays in Yen for a Campaign Priced in Euros

Related loop: Design a Payment Processing System, step 3.4 (FX).

Step 3.2: Fake Backers Pushed a Campaign Over Its Goal, and Small Pledges Are Testing Stolen Cards

Primitive: Bot Defense, Sybil Resistance and Registration Abuse · related loop: the payment loop's step 3.3 (card testing)

Step 3.3: 2,000 New Campaigns a Day, Some of Them Scams or Prohibited

Synthesizing vector architecture diagram...

The campaign lifecycle as it stands after Round 3 (Round 1's CANCELLED branch is unchanged and left out). SUSPENDED can be reached from any state where backers could still be harmed. It ends in a refund saga when money was collected; a campaign suspended while still LIVE has charged nobody, so its pledges are simply released. Every arrow is one conditional status update.

Step 3.4: A Funded Campaign Turns Out to Be a Scam: Refund 500,000 Backers

Primitive: Two-Phase Commit and Saga Orchestration

Drill: The flight booking that charged without a seat (a compensation that fails halfway is point 1: every refund is an idempotent, recorded step resumed from the pledges' states, and a refused refund becomes a case; why a saga and not 2PC is step 2.3's third wrong answer)

Step 3.5: A Region Fails at 23:59 With Three Settlements in Flight

Synthesizing vector architecture diagram...

The deterministic key is what makes lost records safe: the new writer can only ask the PSP the same question again, and the PSP answers from memory.

Primitive: Cloud Disaster Recovery and Multi-Region Active-Active · loop primitive Multi-Region Failover · related loop: the hotel reservation loop, step 3.6

Step 3.6: Chargebacks Arrive Months After Payout Because Rewards Didn't Ship

A chargeback, posted. One €60 pledge from the gadget campaign, disputed in January; we assume a fee equivalent to the US $15 for illustration and that the reserve still holds money.

Related loop: the payment loop's step 2.6 (payout returns and negative balances).

Round 3 Step Summary

R3.5 Global Architecture

One home region in detail; the other two are the same shape.

Synthesizing vector architecture diagram...

Everything that decides money for a campaign is in its home region, on one writer. Everything browsers read is a copy. The PSP budget is split between regions and lent back and forth, so no region depends on another to charge.

• Regional stacks as in Round 2, one per home region, each with a Global Database secondary in a nearby region.
• Global pages: CloudFront serves each campaign page; the origin is the nearest region, which holds a read copy of every campaign's page data built from the other regions' change streams, seconds stale.
• Risk service per region: rules and a model scoring pledges and creators on the pledge path.
• Moderation module per region, with a shared reviewer tool.
• FX: the payment platform's quotes and rates, used for estimates (and quotes if we ever charge in the backer's currency).
• Outbound creator webhooks: a sender fleet with HMAC signing, retries and an egress path that refuses internal addresses.
• Audit export: each region's ledgers exported nightly to S3 with Object Lock, as in the payment loop's step 3.6 (tamper evidence); we don't re-teach it.

Trace 1: a cross-currency pledge and charge. The Osaka backer opens the Munich campaign from ap-southeast-1's cache ("about ¥9,780"), pledges €60, and the request is routed to eu-central-1, where the risk service scores it (low) and the pledge is inserted in euros. At the deadline, the charge is €60; the backer's bank converts it at the stronger euro, about ¥10,170, plus any fee the bank adds. Our ledgers only ever saw euros.

Trace 2: a scam campaign suspended and refunded. Step 3.4: reports and a risk signal open a case; trust and safety suspend the campaign (payouts and charges stop); after the appeal window the decision is final; the refund saga runs 500,000 refunds at 100 a second in about 83 minutes, taking money from reserve, then balance, then transfer reversal, then platform loss.

Trace 3: a region failover mid-settlement. Step 3.5's sequence: the fence, the promotion, the same keys re-sent, attempt 3 replayed from the PSP's memory, the late deadline closed only after the loss window is reconciled.

R3.6 Numbers and Cost

Pledges.

$$\frac{150{,}000 \times 600}{30} = 3{,}000{,}000 \text{ pledges/day} \approx 35 \text{/s average}$$

By home region: us-east-1 40% (1.2M), eu-central-1 35% (1.05M), ap-southeast-1 25% (0.75M). Launch peaks stay per campaign, as in Round 2.

Settlements. $150{,}000 / 30 = 5{,}000$ campaigns end a day; at 60% funded, $3{,}000 \times 600 = 1.8$M charges a day. Each region's busiest hour, with a quarter of its day's deadlines (an assumption):

The regions' busiest hours are in different time zones, so their peaks rarely overlap; if all three regions share one PSP account, the coordinator lends each region the others' idle share, and a region can charge faster than its fixed share when the others are quiet. A giant campaign still takes about an hour, as in Round 2.

Moderation. 2,000 submissions a day, each checked automatically: its text (a few DetectToxicContent calls) and, we assume, 12 images and one short video of about a minute. That's 24,000 image checks a day. With 15% flagged (an assumption) and 10 minutes per human review, that's $2{,}000 \times 0.15 \times 10 = 3{,}000$ minutes, 50 reviewer-hours a day. Add post-launch reports, which we assume at 500 a day at 5 minutes each, about 42 hours: about 92 reviewer-hours a day, 12 reviewers on 8-hour shifts. People, not servers, are the moderation cost.

Refund saga. 500,000 refunds: about 83 minutes at an assumed 100/s refund budget, 5.6 hours at the default 25/s.

Ledgers and audit. Pledge-ledger entries: $3\text{M} \times 1.15 \times 170 \text{ B} \approx 587$ MB a day. Money entries: $1.8\text{M} \times 3 \times 170 \text{ B} \approx 918$ MB a day. Pledges and charge attempts add about 1.7 GB a day. In Aurora across the three regions: about 1.2 TB a year, plus the same again in the DR secondaries. The nightly audit export compresses the two ledgers, about 1.5 GB a day, to roughly a quarter (an assumption): about 140 GB a year in S3, kept for years at a few dollars a month per year kept.

Availability and recovery. RPO normally under a second, capped at about 20 seconds by rds.global_db_rpo. RTO 10 to 15 minutes, mostly the human decision (the hotel loop's step 3.6 derives it).

Monthly cost (us-east-1 on-demand prices for every region first; the regional adjustment follows):

Other regions cost more. Frankfurt and Singapore charge more than us-east-1 for instances and transfer; they carry about 60% of this spend. We add about 15% to that share (an estimate, to be replaced by the pricing calculator), about $6.9K, for a budget of about $84K a month. Email is still the biggest line.

Against the business. 1.8M charges a day at an assumed $60 equivalent is $108M a day, about $3.2B a month. A 5% platform fee is about $162M a month. The infrastructure is about 0.05% of the platform's fee revenue. The expensive things in Round 3 are people (reviewers, analysts, support) and losses (fraud, unrecovered chargebacks), which is why the design spends its effort on the reserve, the review states and the audit trail.

R3.7 Trade-Offs

Back to the opening question: how do we collect millions of promises safely, and then, at one instant, turn each one into exactly one charge, or release it, for every campaign on the platform? The answer is now: a pledge is a promise, not a payment, and the ledger, not a counter, decides. We save cards instead of charging them, record every promise in an append-only ledger owned by one home region, and close pledging with a fence so the exact sum includes everything accepted and nothing after. Then settlement turns promises into money as a resumable saga, paced by the PSP's limit, with keys per (pledge, attempt) so a retry, a crash or a failed-over region can only ask the PSP the same question again. Around it sit the things that make the money trustworthy: dunning, reconciliation before payout, a double-entry money ledger, reviews before outcomes, and reserves for the disputes that come after.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals, per region OPS 8 · REL 6

Procedure: a stalled settlement REL 11

1. Look at the campaign's settlement dashboard: charged, failed, unknown, rate, ETA.
2. If the rate is zero with no 429s, the workers are down or not holding leases: check the task count and the job's lease owner.
3. If 429s dominate, someone else is spending the budget: the bucket metrics per caller show who.
4. Resolve stuck CHARGING pledges with their own keys; never create a new attempt for an unknown.

Procedure: a PSP incident at a big deadline OPS 10

1. Confirm on the PSP's status page and our error rates. Open the breaker for charging; keep pledging up (card setup may also be failing: show a clear message).
2. Tell creators whose settlements are affected: "funded; charging is delayed".
3. When the PSP recovers, close the breaker gradually through the bucket; resolve unknowns first.

Procedure: a campaign suspension SEC 10

1. Trust and safety suspend with a reason; charges and payouts stop at once.
2. Freeze the creator's other payouts and linked accounts pending review.
3. After the appeal window, if confirmed: start the refund saga; watch its progress like a settlement.
4. Afterwards: add the pattern to the risk rules; report as regulators and card networks require (keep to our legal team's guidance).

Go deeper: CLI playbook

Plain commands an on-call engineer runs, one at a time. Replace the names and ARNs with real ones.

textCopy
# 1. Alarms currently firing for settlement in a region
aws cloudwatch describe-alarms --region eu-central-1 --state-value ALARM --alarm-name-prefix settlement-

# 2. Depth of the notification queue after a deadline
aws sqs get-queue-attributes --region eu-central-1 --queue-url https://sqs.eu-central-1.amazonaws.com/111122223333/notify-outcomes --attribute-names ApproximateNumberOfMessages ApproximateAgeOfOldestMessage

# 3. The region's SES sending quota and today's usage
aws sesv2 get-account --region eu-central-1

# 4. Replication state of a home region's global database
aws rds describe-global-clusters --global-cluster-identifier cf-eu

# 5. Unplanned failover to the DR secondary (may lose up to about 20 s of commits)
aws rds failover-global-cluster --global-cluster-identifier cf-eu --target-db-cluster-identifier arn:aws:rds:eu-west-1:111122223333:cluster:cf-eu-euw1 --allow-data-loss

# 6. State of the region's CDC connector
aws kafkaconnect describe-connector --region eu-central-1 --connector-arn arn:aws:kafkaconnect:eu-central-1:111122223333:connector/cf-eu-cdc/1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d-2

# 7. State of the region's cache (totals, tier counts, token buckets)
aws elasticache describe-replication-groups --region eu-central-1 --replication-group-id cf-cache

Audit queries (read-only, against a region's replica):

sqlCopy
-- A decided campaign's promise entries must add up to its decision. Should return nothing.
SELECT c.campaign_id, c.final_minor, SUM(l.delta_minor) AS promises
FROM campaigns c JOIN pledge_ledger l ON l.campaign_id = c.campaign_id
WHERE c.status IN ('FUNDED','SETTLING','SETTLED','COLLECTED','RECONCILED','PAID_OUT')
  AND l.kind IN ('ACTIVATE','CHANGE','CANCEL','REMOVE')
GROUP BY c.campaign_id, c.final_minor
HAVING SUM(l.delta_minor) <> c.final_minor;

-- No pledge may have two successful charges (the unique index makes this impossible).
SELECT pledge_id, count(*) FROM charge_attempts WHERE status = 'SUCCEEDED' GROUP BY pledge_id HAVING count(*) > 1;

-- Journals must balance. Should return nothing.
SELECT journal_id, SUM(amount_minor) FROM money_entries GROUP BY journal_id HAVING SUM(amount_minor) <> 0;

-- Charges in flight too long: resolve by key, and by lookup after 24 hours.
SELECT pledge_id, attempt_no, created_at FROM charge_attempts
WHERE status = 'IN_FLIGHT' AND created_at < now() - interval '10 minutes' ORDER BY created_at;

The first query needs no time filter: after the fence, no transaction can add an ACTIVATE, CHANGE or CANCEL entry, and REMOVE entries (step 3.2's fake pledges) are written only before the decision. Post-close entries (DROP) are a different kind. A row in this result means the fence failed, which is exactly what an audit should catch.

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Keeps one currency per campaign's goal and ledger, and shows why FX can't flip an outcome.
• Connects the "stays funded" policy to the fraud it invites, and puts a review before the outcome instead of changing the policy.
• Treats moderation as its own module with its own states, automated first and human for what's flagged.
• Designs mass refunds as the mirror of settlement, with a stated order for where the money comes from and a loss account for what's left.
• Fails over a home region with fences, resumes settlement from the pledges' states, and explains why deterministic keys make lost records harmless.
• Owns the money after payout: chargebacks as journals, a delivery-aware reserve, evidence from the campaign's own records.

Follow-up questions

1. "Why not DynamoDB global tables for pledges, so every region can accept them?" Answer: global tables check condition expressions against the local copy and resolve conflicting writes with last-writer-wins by default, so two regions could each take the last Early Bird slot, and the funded decision would depend on which copy you summed. The multi-Region strong-consistency mode runs in exactly three Regions and doesn't support transactions, and a pledge is a transaction over a pledge, a ledger entry and a tier counter. One writer per campaign is simpler and correct.

2. "A creator moves countries. Can their campaign move home regions?" Answer: only between campaigns, or as a planned migration while it isn't settling: freeze pledges briefly, copy the campaign's rows, verify the ledger sum, flip the routing, and have the old region refuse that campaign's writes for good. We never move a campaign mid-settlement.

3. "The review found 900 fake pledges and the campaign falls below its goal without them. What now?" Answer: the fake pledges are removed with compensating entries while the campaign is UNDER_REVIEW, before any outcome was decided, so the exact sum without them decides: unsuccessful, and every real backer is released without being charged. The creator is investigated for the linked accounts.

Interview gotchas from this round's wrong answers

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint.

The Two Sentences That Matter Most

• Opening a round: "A pledge is a promise, not a payment: I collect promises for weeks and move money once, at the deadline, as a resumable saga."
• When someone points at the counter: "Totals can lag; decisions can't: the page shows a counter, but the funded decision and every charge come from the ledger."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels

See It Built: the Reference Implementation

~5 min.

CrowdFundingHub is a C# (.NET) modular monolith that implements Round 1's design and parts of Round 2: one deployable application, one PostgreSQL database with a schema per module, modules that talk to each other only through published contracts and events carried by a transactional outbox, and inboxes that make every consumer idempotent. It's the codebase behind an upcoming course on clean architecture; the repository is private, so this section describes it rather than linking to it.

A modular monolith is a sensible shape for Round 1: one database and one deploy keep the fence and the ledger simple, while the module boundaries mean a piece like Moderation could later be moved into its own service without untangling shared tables.

Where it differs from this page's design (checked against the code on 2026-09-28; the codebase is under active development):

• It charges at pledge time and refunds if the campaign fails: the charge-now model from step 1.1, a legitimate simpler choice, rather than save-and-charge-later.
• It recomputes the raised total as a sum over the ledger under a per-campaign lock on every pledge: exactly right at Round 1's scale, and exactly what step 2.1 replaces.
• Fees are metered, not yet posted to a double-entry money ledger, and there are no creator payouts yet.
• Its refunds record state only: the handler that reacts to a failed or cancelled campaign marks contributions refunded in batches of 100, and the late-success case marks a payment refunded, without yet calling the payment provider's refund API.
• Its 15-minute tier reservations match step 1.4's hold, but they exist for its charge-now checkout, not for card setup.