Design a Donations Website: Safe Payments and Live Totals

Organisers create a campaign with a title, a story, a cover photo and a goal, for instance ten lakh rupees for a medical bill. Donors contribute through an external payment provider using a card or UPI, which keeps sensitive payment handling outside our own services.

The campaign page shows how much has been raised, a progress bar against the goal and a short list of the latest donors, refreshed in near real time so supporters feel momentum. Each donor receives an email receipt once the payment is confirmed, not when they click the button. Transferring funds to organisers and processing refunds are real features of such a product, but each brings its own compliance and ledger concerns, so they are set aside here.

Payment correctness is the top priority. The effect of each donation must be exactly once: the donor is charged a single time and the platform records it a single time, regardless of retries, timeouts or duplicate notifications. The displayed total does not need that rigour. If the progress bar runs a few seconds behind reality, nobody is harmed, so it can be eventually consistent.

The system must absorb viral bursts where a single campaign suddenly receives thousands of donations per second. Security rounds out the list: card data is entered on the provider's checkout and never touches or is stored by our servers, which keeps the scope of PCI compliance small and reduces what an attacker could steal.

Assume about 2 million donations a day. Spread evenly, that is only around 23 per second, a load any single database handles easily. The average is misleading, though. A viral campaign can draw roughly 5K donations per second on its own, and if each donation corresponds to about 100 people simply watching, that one page sees around 500K views per second at its peak.

Storage is modest. At about 1 KB per donation record, the platform adds roughly 2 GB per day, or around 730 GB per year. So the challenge is not total volume. It is concentration: one campaign, one running total, and thousands of increments per second all targeting the same piece of data, which a single database row cannot absorb.

Four entities cover the domain: Campaign, Donation, Payment (the record that lives at the provider) and Donor. Keeping Donation and Payment separate lets our ledger track its own state machine while still pointing at the provider's transaction ID for audits and reconciliation.

POST /campaigns creates a campaign from a title, story and goal. GET /campaigns/{id} returns the story, amount raised, goal and recent donors. POST /campaigns/{id}/donations takes an amount and an idempotency_key and returns a donation ID together with a payment session for the provider's hosted checkout. Finally, POST /webhooks/payments is called by the provider, not by users, with an event ID, payment ID and status, telling us whether the charge succeeded or failed.

The front door is an API gateway that checks identity and enforces rate limits. Campaign page views are handled by the campaign service, which returns stored details and reads the live total from Redis, so heavy viewing never reaches Postgres.

A donation follows a stricter route. The donation service inserts a pending record in Postgres, keyed by the idempotency key, and then opens a payment with a provider such as Stripe or Razorpay. The donor completes payment on the provider's checkout page, and the provider later calls our webhook with the outcome. Only at that point is the donation marked paid.

In the same transaction that marks it paid, the service writes an event to an outbox table. A relay publishes outbox rows to Kafka, and an aggregator consumes donation events per campaign and increments that campaign's Redis total by each amount. The outbox guarantees that a confirmed donation always produces its event, and the progress bar catches up within a few seconds.

Preventing double charges starts on the client. When the donate form opens, the app generates a unique idempotency key and reuses it for every retry of that donation, including the second tap from a nervous user on a flaky connection. The donations table enforces a unique constraint on this key, so the first request creates the pending row and any repeat simply finds that row and returns the identical response.

The same key is forwarded to the payment provider, which applies its own deduplication; even if our service times out and calls the provider again, the card is debited only once. Webhooks are verified by checking the provider's signature, and processed event IDs are recorded so a redelivered event is ignored. Donation state only moves forward, from pending to paid or failed, never back.

Webhooks can arrive late or not at all. Once a day, a reconciliation task lines up every ledger entry against the provider's settlement report, marks missing successes as paid, and flags anything that does not match for review.

Updating a raised column on the campaign row for each donation is exact, but at 5K donations per second every transaction contends for that one row lock and the queue of writers grows without bound. Computing SUM(amount) across all donations on each page view avoids extra state, but doing it 500K times per second would overwhelm the database.

Sharded counters solve both problems and are the chosen design. Each campaign gets a set of counters, say 16 Redis keys, and every donation applies INCRBY to one of them picked at random, spreading the writes. Reading the total means adding the 16 values, and that sum is cached for a second or two so viewers do not repeat the work.

Kafka delivers at least once, so the aggregator remembers which donation IDs it has already counted and skips duplicates. A periodic job recomputes each total from the Postgres ledger and corrects any drift, which keeps the fast path honest.

When a campaign goes viral, most traffic is people looking, not paying. The CDN caches the campaign page itself, including story, photos and layout, so only the total needs a live fetch. Browsers re-request just that figure on a timer of a few seconds, and it comes from a cache entry that lives only briefly, which means half a million viewers are served from memory rather than from the database.

The donation service holds no state and each donation is a simple insert, so it can autoscale horizontally as traffic rises. Popular campaigns also attract card-testing fraud, where bots try stolen cards with tiny amounts; rate limits per IP address and per card, combined with the provider's fraud screening, block most of it. The recent donors list lives in a Redis list trimmed to the latest fifty entries, which makes rendering it trivial.

Sharded counters handle extreme write bursts, but the total lags by a few seconds. Webhooks are faster and cheaper than polling the provider, yet they can be delayed or dropped, which is why reconciliation exists. The outbox plus Kafka ensures no confirmed donation is ever missing from the totals, at the cost of operating another component.

Aggressive caching keeps the site standing under huge traffic while visitors may see slightly older figures. The rule underneath all four decisions: demand precision for money, accept delay for displayed totals, and serve everything else from cache.