Problem Statement: Conditional Commerce, Not a Shopping Cart
Frames crowdfunding as commerce gated by a funding predicate, where money moves only if a threshold is crossed before a deadline.
Problem statement
Design a crowd-funded product platform in the Kickstarter mold: creators publish campaigns with a funding goal, a deadline, and reward tiers; backers pledge money against a reward; if total pledges reach the goal by the deadline the campaign is funded and money is collected; otherwise no backer is charged and the campaign ends with nothing collected. The platform must handle campaign creation and review, pledge intake at launch spike scale, conditional capture of funds, reward tier inventory, stretch goals, a reliable release/refund path for failed or cancelled campaigns, creator payouts, and campaign analytics.
This is not e-commerce with longer shipping times. In normal retail, each order is independent and payment is immediate. In crowdfunding, a pledge is a conditional promise to pay: the money event happens later, in bulk, driven by a deadline and an aggregate predicate. That single difference creates the entire architecture. The platform must be correct about time, about aggregate totals, and about money state transitions — and it must survive the two moments where everything concentrates: the launch stampede and the deadline settlement.
Why the problem is distinctive
Three properties separate this from a marketplace or storefront. First, time-triggered settlement: at the deadline, every campaign flips to SUCCESS or FAILED based on authoritative totals, and that flip gates irreversible money movement for thousands of backers at once. The evaluation must happen exactly once, on an authoritative number, regardless of traffic or partial failures. Second, conditional money movement: pledges are promises, not payments. Cards are tokenized at pledge time and charged only after success (the all-or-nothing model), or charged immediately with a refund obligation (flexible funding). Either way the pledge lifecycle is a payment state machine, not a one-shot charge. Third, extreme load skew: a celebrity or viral launch can concentrate tens of thousands of pledges per minute on a single campaign row while the rest of the platform is quiet. The hot key is the campaign, and the design must absorb that without degrading the money path.
Public operating baseline
The category is proven and the failure modes are documented. Kickstarter's public stats page reports roughly eight-plus billion dollars pledged cumulatively since 2009 across a few hundred thousand successfully funded projects, with tens of millions of backers. Its most-funded project, Pebble Time, raised about 20.3 million dollars from roughly 78,000 backers in 2015, a launch intense enough to visibly degrade the site at the time. Exploding Kittens set the backer-count record with nearly 220,000 backers on a small-ticket campaign, stressing row count and notification fan-out rather than dollars. Indiegogo, founded in 2008, publicly advertises both fixed (all-or-nothing) and flexible funding plus an InDemand mode that keeps raising after the campaign ends. GoFundMe popularized keep-it-all personal fundraising at tens of billions cumulative. And the Coolest Cooler, which raised about 13.3 million dollars in 2014, became the canonical fulfillment disaster: funded, collected, and then unable to deliver, which is why pledge-management companies like BackerKit grew into a layer between funding and shipping.
These are cited public figures, context for the design. Every uncited number in this answer is an explicit design assumption, budget, or target.
The four architectural planes
- Campaign plane: catalog, campaign lifecycle, reward tiers, stretch goals, deadlines, discovery, and analytics.
- Money plane: pledge ledger, tokenized payment methods, conditional capture, retries, refunds/releases, fees, creator payouts, reconciliation.
- Community plane: backer accounts, creator profiles, updates and comments, notifications, and the fan-out those cause.
- Trust plane: campaign review, fraud scoring, KYC before payout, chargeback handling, moderation, and audit.
A strong answer keeps the planes separate. The campaign plane may degrade (stale totals, queued notifications) without corrupting the money plane, and the money plane never depends on the community plane being up. If a launch spike melts the page cache, pledges still record correctly; if the payment processor wobbles during collection, the grace window absorbs it without changing the campaign outcome.
Key Highlights
- •A pledge is a conditional promise to pay, not a purchase; the charge happens later and in bulk, gated by a deadline predicate.
- •Deadline settlement must be exactly-once and computed from authoritative totals, never from a cached counter.
- •Load is extremely skewed: one viral campaign can dominate writes, so the campaign row is the hot key to design around.
- •Four planes: campaign, money, community, trust. Money correctness is never traded for page freshness.
- •Public history anchors the design: Kickstarter's all-or-nothing model, Indiegogo's flexible funding, Coolest Cooler's fulfillment collapse.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate campaign progress, which can be eventually consistent, from settlement totals, which must be authoritative."
- "Before choosing stores, let me define which events move money and which only move pixels."