Design Venmo

80 M users paying friends instantly: 15 M transfers a day on a sharded double-entry ledger, funded and cashed out over slow bank rails.

Last updated 2026-10-26. Difficulty: hard. Patterns: ledger, sharding, hot-keys, fraud, fintech. Reported at PayPal, Stripe, Coinbase, Robinhood, Amazon, Google.

Functional requirements

• Send money to a friend instantly. From the in-app balance, or funded by a linked bank account or card when the balance is short. The recipient sees it in their balance within a second. A card-funded send charges the card through a processor (3 % for credit cards); a bank-funded one may be lent to the sender instantly, within a limit, before the bank debit settles.
• Request money. A request moves no money: it sits on the payer’s shard until they pay it, decline it or it expires after 30 days. Paying uses the request id as the idempotency key, so a request can be paid at most once however many times the button is tapped.
• Balance: available and current, with pending items. Current is settled money; available subtracts holds (a cash-out in flight, a risk hold on money received by a new account). Pending deposits and holds are listed with a reason and a date. Transaction history is exact because it is read from the ledger.
• Link funding sources and add money. Link a bank by bank login through an aggregator such as Plaid, or by micro-deposits, and link debit or credit cards. Adding money from a bank is an ACH debit: pending until it settles, unless instant credit covers it.
• Cash out to a bank account or debit card. Standard is an ACH credit: free, one to three business days. Instant is a push-to-card credit that lands in seconds to minutes, for 1.75 % with a $0.25 minimum and a $25 cap.
• Social feed with per-payment privacy. Friends’ payments with their notes, never the amounts. Each payment is public, friends-only or private; the stricter of the two people’s settings applies, and changing it later hides the item everywhere within a second.
• Risk, limits and compliance in the money path. KYC tiers with weekly send and cash-out limits, sanctions screening, fraud checks on every send and cash-out, holds for new accounts, and an audit trail for every movement and every manual adjustment.
• Never create or lose money. Every movement is a balanced ledger entry. Every night the ledger is reconciled against the pooled bank accounts and the card networks, and the cash held must cover what users are owed.
• Out of scope. The card-acceptance machinery behind card funding (Design a Payment System covers it), merchant checkout and purchase protection, a debit card for spending the balance (its authorisations would be holds like the ones here), crypto, tax forms, and currencies other than USD.

Non-functional requirements

• Money is conserved (Σ postings = 0 · cash ≥ balances owed). No double debit, no lost credit, and no balance its postings cannot explain. The pooled bank accounts must cover what users are owed at every daily close. This ranks above latency and availability.
• No overdraft by a user (available ≥ 0 after every user debit). Two concurrent sends cannot both spend the same $40; only a system reversal after a bank return can take a balance below zero. This drives the hardest tradeoff: the funds check is a serialised decision per account, which is exactly what makes hot accounts and cross-shard transfers hard.
• Send latency (p99 < 500 ms from balance). Our own path is a 50 ms risk check and one local transaction, about 150 ms typical; the recipient sees the credit within a second. Card-funded sends add the processor round trip of 300 to 800 ms.
• Scale (80 M users · 15 M transfers/day · 1 k/s peak). Friday nights and holidays run about 6× the 175/s average. Throughput is modest; the difficulty is contention on hot accounts and money that settles over days.
• Availability of sends (99.99 %). A shard failover may delay credits by seconds to a minute but must never lose one. The feed, notifications and analytics can degrade without touching money.
• Risk decision budget (p99 < 50 ms). Synchronous checks use precomputed features and live counters only. Anything slower runs asynchronously and acts through holds before money leaves the wallet.
• Auditability and retention (append-only · kept ≥ 5 years). Every movement has an entry, a cause and an external reference; manual adjustments need two approvers. Five years is the Bank Secrecy Act’s record-keeping minimum; we keep seven.
• Privacy (amounts never in the feed). Visibility is checked at read time against the current setting, so a payment made private disappears within a second, including from precomputed timelines.

Back-of-envelope estimates

• Transfers per second: ~175/s avg · ~1 k/s peak. 15 M/day ÷ 86 400 ≈ 174/s. Friday evenings and holidays run about 6× the average: ~1 k/s. Each transfer is two local transactions (a debit leg and a credit leg), so ~2 k ledger transactions/s at peak across the fleet. One large Postgres primary could take that; throughput is not what shapes the design.
• Ledger postings per day: ~90 M. A cross-shard transfer is two entries of two postings each (4). Funding, fees, cash-outs, settlements and returns add about 2 more per transfer on average, so ~6 postings per transfer: 15 M × 6 = 90 M a day, ~1 k/s average and ~6 k/s at peak.
• Ledger storage: ~5 TB/yr raw · ~35 TB over 7 years. 90 M × 150 B ≈ 13.5 GB/day ≈ 4.9 TB/yr before indexes, about double with them. Append-only and kept seven years. The last 18 months stay on the shards (~1 TB each across 16), partitioned by month; older partitions move to columnar storage with the same schema.
• Cross-shard share: ~94 % of transfers. Accounts are hashed across 16 shards, so the receiver is on the sender’s shard with probability 1/16: 15/16 ≈ 94 % of transfers cross shards. The two-leg path is the normal path, not the exception, so it has to be fast and boring.
• One balance row’s ceiling: ~330 updates/s. Every debit or credit holds the account’s row lock for its whole transaction, ~3 ms with a synchronous standby commit, so one row serialises at most 1 ÷ 0.003 ≈ 330 updates a second. A viral fundraiser receiving 2 k/s is 6× over. That is why credits to one receiver are batched (~200 per transaction) and system accounts get no balance row at all.
• ACH money at risk: ~$150 M/day lent · ~$1.5 M/day returned. 3 M bank-funded sends a day × $50 = $150 M credited before the debits settle; a holiday weekend keeps about four days, ~$600 M, outstanding. At a 1 % return rate, $1.5 M a day comes back after the recipient may already have cashed out, and unauthorised returns can arrive up to 60 days later.
• Feed fan-out: ~1.8 B timeline writes/day. 15 M payments × 60 % not private × 2 participants × ~100 active friends each = 1.8 B writes a day, ~21 k/s average and ~125 k/s at peak. That is 20× the ledger’s postings and none of it is money: it belongs in its own store and may lag by seconds.
• Reconciliation volume: ~7 M external records/day. ACH debits (3 M bank-funded sends + 0.5 M add-money) + ACH credits (1.2 M standard cash-outs) + push-to-card (0.8 M instant cash-outs) + card charges (1.5 M card-funded sends) ≈ 7 M lines a day to match against ~90 M postings. A batch job does it in minutes; the cost is investigating breaks, not the volume.

Components

• Venmo app (iOS · Android · web): Sends, requests, cash-outs and the feed. Generates an idempotency key when a payment screen opens and reuses it on every retry of that payment, so a double tap or a lost response can never send twice. Shows the available balance as the big number, with pending items and holds listed under it.
• API gateway (auth · device binding · step-up): Authenticates the user and the device, rate-limits per account and device, and routes to the transfer and feed services. Carries step-up challenges (a one-time code, an ID check) back to the app when risk asks for them. Rejects any money-moving call without an Idempotency-Key.
• Identity & limits (KYC tiers · sanctions): Holds each user’s verification tier (phone only, identity verified, enhanced) and the weekly send, receive and cash-out limits that go with it, and screens users against sanctions lists at sign-up and on every list update. The limit values are cached by the transfer service; the running weekly totals are enforced inside the debit transaction on the sender’s shard, so two concurrent sends cannot both slip under a limit.
• Risk service (rules + GBT · ≤ 50 ms): Scores every send and cash-out within 50 ms from precomputed features and live velocity counters, returning allow, block, step-up, or allow with a hold on the received funds. On timeout it falls back to rules by irreversibility: sends from balance inside the wallet continue, money leaving the wallet does not. Logs every decision with its features, for training on labels that arrive weeks later.
• Risk features (Redis · velocity counters): Counts and sums per sender, receiver, device, IP and bank link over 1 minute, 1 hour and 24 hours, incremented atomically at decision time so a burst of parallel sends sees itself. Slower features (account age, return history, graph links to known fraud) are written here by offline jobs. Losing it degrades risk to fallback rules; it holds no money.
• Transfer service (sends · requests · cash-outs): Owns the workflow of a send, a request and a cash-out: resolves the recipient, checks limits, asks risk, picks the funding path, then asks the ledger to post. Stateless: the transfer record is written by the ledger on the sender’s shard, in the same transaction as the debit. Routes every send to the sender’s shard, the only place a send is decided.
• Money movement (ACH · cards · push-to-card): Talks to the slow outside rails. Creates ACH debits and credits and submits them in Nacha files through the partner bank, charges cards through a processor, sends instant cash-outs over push-to-card, and processes return files. Each external transfer has its own state machine (created, submitted, settled, returned) and posts its outcome to the ledger idempotently.
• Card networks (processor · Visa Direct / Mastercard Send): Card charges for card-funded sends go through a processor; instant cash-outs go out as push-to-card credits, which reach a debit card in seconds to minutes and settle from our settlement account the next business day. A push can time out after it has paid, so every call carries our reference and can be queried.
• Feed service (read model · privacy): Builds the social feed from completed transfers: applies the stricter of the two people’s privacy settings, drops the amount, and fans the item out to friends’ timelines. On read it re-checks each item’s current visibility and any blocks, because a timeline is a copy and a payment made private must vanish at once. It never reads the ledger; if it lags or fails, no money is affected.
• Feed store (Cassandra · timeline per user): One partition per viewer, clustered by time: payment id, the two people, note and a visibility version, never the amount. ~1.8 B writes a day, 20× the ledger, with a 30-day horizon. Beside it a small visibility table keyed by payment id holds the current setting that every read checks.
• Ledger service (double entry · two legs): The only writer of money. Posts balanced entries, keeps each user’s cached balance in the same transaction, places and resolves holds, and runs a transfer as two local legs: the debit on the sender’s shard, the credit on the receiver’s. Leg-2 appliers consume the bus by receiver and batch credits for hot accounts; every leg is idempotent on (transfer_id, leg).
• Partner banks (pooled FBO accounts · ACH): Hold user money in pooled for-benefit-of accounts, originate our ACH files, and send prior-day statements (BAI2) and return files. They see only aggregates, never our 80 M user accounts. Our ACH return rates are their regulatory exposure, so they watch them too.
• Event bus (Kafka · from outbox): Transfer events published by an outbox relay, so an event exists exactly when its transaction committed. Keyed by the receiver’s account, so every credit to one account is in order on one partition and one applier can batch them. Consumers: leg-2 appliers, the feed, notifications, risk feature jobs and analytics.
• Ledger shards (Postgres × 16 · by account): Journal entries, postings, balances (current, held, sent this week), transfers with their idempotency keys, requests and the outbox, for the accounts hashed to that shard. Postings in an entry must sum to zero, and the application role can insert them but never update or delete them. Each shard has its own transit, fee and clearing accounts with no balance row, so system accounts never become hot rows.
• Reconciliation (daily close · as of cutoff): Runs after midnight Eastern. Checks that every entry balances and every cached balance equals its postings, then matches each pooled bank account and clearing account to statements and settlement reports, line by line. Proves that user balances equal cash held plus money in flight, and that cash covers what users are owed. Breaks become cases; it never posts a correction itself.

User flows

1. Send $40 from balance to a friend. The core write. Alice’s shard decides everything (funds, limits, idempotency) in one local transaction; Bob’s shard applies a credit that cannot fail. Two local transactions joined by an outbox event, with no lock held across the network.
   1. Alice taps Pay; the app sends the recipient, amount, note, visibility and the idempotency key it generated when the payment screen opened. The key is created once per payment screen and reused on every retry, so a double tap or a response lost in a tunnel is the same payment, not a second one. The gateway checks the session is bound to this device and rejects money-moving calls without a key. Amounts are integer cents.
   2. The transfer service checks Alice’s tier and limits and asks risk for a decision with a 50 ms deadline. Alice is identity verified, which allows $5 000 of sends a week. Risk reads precomputed features and increments velocity counters for sender, device and receiver in the same call, so twenty parallel sends from a script each see the ones before them. Bob is a known payee and the amount is small: allow.
   3. Leg 1 runs on Alice’s shard as one transaction: insert the transfer with its key, debit Alice only if her available balance covers it, credit the shard’s transit account, and write an outbox event. The funds check is inside the UPDATE, so two concurrent sends serialise on Alice’s row and the second is re-checked against the new balance. The weekly limit is checked in the same statement. The transit account has no balance row, so it never contends. A repeated idempotency key fails the unique insert and the stored result is returned instead.
   4. Alice’s app gets “sent” as soon as leg 1 commits. Leg 1 is the commit point: the money has left Alice, and the credit is promised by a committed outbox row, so the answer does not wait for Bob’s shard. If Bob’s shard is mid-failover, Alice still sees sent and Bob sees the credit seconds later. A balance-funded send takes about 150 ms end to end; the status turns to completed when leg 2 lands, usually within 200 ms.
   5. The outbox relay publishes transfer.debited to the event bus, keyed by Bob’s account. The event exists if and only if leg 1 committed, because it was written in the same transaction. Keying by the receiver puts every credit for one account on one partition, in order, which is what later lets a hot receiver’s credits be batched.
   6. Bob’s shard’s credit applier runs leg 2: debit its transit account, credit Bob, raise his cached balance, and emit transfer.credited. There is no funds check, because receiving money needs no permission: a frozen account can still receive, and only a closed one is refused (credited to a suspense account, then reversed to Alice). The unique (transfer_id, leg) makes a redelivered event a no-op. Leg 2 usually lands 50 to 200 ms after leg 1.
   7. The feed service consumes transfer.credited, applies the stricter of the two people’s privacy settings, and writes the item, without the amount, to their friends’ timelines. The payment is friends-only, so about 200 timelines get it: Alice’s and Bob’s active friends, deduplicated. At ~1.8 B such writes a day the feed is 20× the ledger’s postings, which is why it is its own store and may lag by seconds. If the feed is down, nobody’s money is affected.
   8. A friend opens the feed; each item’s current visibility and any blocks are re-checked before it is shown. A timeline is a copy. If Bob switched the payment to private ten seconds ago, the visibility table has a newer version and the item is dropped even though it still sits in the timeline; a background job deletes it later. Precomputed copies are never trusted for privacy.
2. A fundraiser receives 2 k payments a second. The scale-breaking case. One cached balance row takes about 330 updates a second, and a viral relief drive on a holiday evening sends six times that. Credits cannot fail, so they are batched; debits from a hot account can fail, so that work is reshaped instead.
   1. A relief fundraiser goes viral on New Year’s Eve: 2 k payments a second to one account, from senders on every shard. Each sender’s leg 1 runs on the sender’s own shard, so the 2 k debits a second spread across all 16 shards and never touch the fundraiser’s row. The whole pressure lands on leg 2: one account on one shard.
   2. Risk sees the receiver’s velocity spike and checks that the account is verified for this volume. A sudden flood into one account is also what a scam looks like. A verified charity profile has a high receive limit and passes; an unverified personal account getting this would keep receiving, with its cash-outs held for review. One Redis counter at 2 k increments a second is far below what a single key can take.
   3. Every leg-2 event for the fundraiser arrives in order on one bus partition, because events are keyed by the receiver. 2 k small events a second is well within one partition’s throughput. Having them all in one place, in order, lets one applier instance own the account, so it never fights itself for the row lock.
   4. The applier drains up to 200 events at a time and posts them in one transaction: 200 entries and one balance update for their sum. 2 k credits a second become 10 to 20 transactions a second on the row, far under the ~330 ceiling, for at most ~50 ms of added delay. The sum covers only the entries actually inserted, so a redelivered event is never counted twice. This is safe only because credits cannot fail; debits could not be batched this way.
   5. The shard’s transit and fee postings pile up as well, but system accounts are append-only with no balance row, so they never contend. Nothing ever checks sufficient funds on a transit or fee account, so nothing needs a row updated in every transaction. Their balance is a one-minute rollup plus the postings since, and the nightly close checks them.
   6. Each payment fans out to the payer’s friends, not to the fundraiser’s 300 k followers; the fundraiser’s own page reads its activity directly. Accounts with more than 5 k friends or followers are left out of fan-out and merged at read time, the celebrity rule from the news feed. Otherwise one hot receiver would cost 300 k timeline writes per payment, 600 M a second.
   7. The organiser later pays 10 k volunteers: one conditional debit for the total into a batch account, then 10 k credits that never touch the organiser’s row. A hot sender cannot be batched blindly, because each debit must pass the funds check. So the job becomes one debit with one check, plus 10 k leg-2 credits from a system account with no balance row. The batch has one idempotency key, and each line’s transfer id is derived from it.
3. Bank-funded send, then the debit bounces. Alice pays Bob $300 from her linked bank. ACH takes days, so either we lend her the money now within a limit or Bob waits. Two banking days after settlement her bank returns the debit for insufficient funds, and Bob has already cashed out.
   1. Alice, with $10 in her balance, pays Bob $300 funded by her linked bank; the transfer service checks her instant-credit limit and asks risk. Her instant-credit limit is $500 a week: the bank was linked by bank login months ago, the owner name matches her KYC name, and she has 20 settled debits and no returns. $300 fits, so Bob is paid now. Above the limit, the transfer would wait in awaiting_funds until the debit settles plus the two-banking-day return window, three to five business days.
   2. The funding service creates the ACH debit, keyed by the transfer id, and the ledger posts a provisional credit to Alice against an ACH receivable. The receivable is our risk, named in the ledger: the sum of ach_receivable is exactly the credit we have extended and not yet collected, ~$150 M a day and ~$600 M over a holiday weekend. Alice’s balance goes to $310 and leg 1 takes it back to $10, in one transaction on her shard.
   3. Legs 1 and 2 run as for any send; Bob has $300 within a second and cashes it out instantly. From Bob’s side the money is final. That is the product promise, and it is why the risk sits with us and the sender, never with a recipient who was paid in good faith.
   4. The funding service submits the debit in the next ACH file to the partner bank; it settles in one to two business days. Same Day ACH windows let us submit several times a business day, but a Friday-night send goes out on Monday morning, which is why holiday weekends carry the most credit outstanding. On settlement the bank statement shows the batch and the ledger posts DR bank_fbo, CR ach_receivable.
   5. Two banking days after settlement, the bank’s return file carries R01, insufficient funds, for Alice’s debit. Insufficient-funds returns must come back within two banking days; unauthorised ones (R10) can arrive up to 60 days later, which is why a fraudulent bank link is far more dangerous than an empty one. The funding service matches the return to the transfer by trace number.
   6. The ledger posts the reversal without a funds check, and Alice’s balance goes to −$290. This is the only path that can take a balance below zero: a system reversal of money that has already left. The negative balance is a receivable from Alice, and the ledger shows it honestly instead of hiding it in a loss account.
   7. Collections: Alice’s account is restricted, incoming money repays the debt first, the debit is re-presented once, and after 60 days the rest is charged off. Restricted means no sends, cash-outs or instant credit, and that bank link’s limit drops to zero. Nacha allows an insufficient-funds debit to be re-presented up to twice; we try once, timed after a likely payday. A charge-off posts DR bad_debt, CR alice, bringing her to zero while the debt goes to an agency, and the return becomes a label for the risk model.
4. Instant cash-out to a debit card. Bob moves $500 to his debit card in seconds for a 1.75 % fee. Push-to-card is irreversible and can time out after it has paid, so the debit is a hold until the network’s answer is known, and settlement is checked the next morning.
   1. Bob asks to cash out $500 instantly to his linked debit card; the app shows the $8.75 fee next to the free standard option. Standard is an ACH credit: free, one to three business days. Instant is 1.75 %, with a $0.25 minimum and a $25 cap. The fee pays for per-transaction network costs and for the risk of an exit nobody can reverse.
   2. Risk checks the cash-out, because money leaving the wallet is the last point where fraud can be stopped. A card linked in the last 24 hours, a receive hold, or money that arrived through instant-credit ACH not yet settled would make this standard-only. Bob’s $500 came from friends’ settled payments and his card is eight months old: allow. His tier allows $20 000 of cash-outs a week.
   3. The ledger places a hold for $508.75: a pending entry that lowers Bob’s available balance but not his current one. Holding first, rather than posting, keeps the books honest while the outcome is unknown. Available drops at once, so Bob cannot spend the same money while the push is in flight.
   4. The funding service sends a push-to-card credit over Visa Direct or Mastercard Send, with the cash-out id as its reference. The outcome has three values: approved, declined, or unknown (a timeout or a 5xx), the same discipline as a payment system’s calls to its processor. The reference is what makes a later status query, and the settlement report, findable.
   5. The call times out; the hold stays, and the funding service queries the push by its reference until it has an answer. Releasing the hold on a timeout would let Bob cash out the same $500 twice if the first push had actually landed. Status queries are safe to repeat; a push still unknown after an hour pages someone, and the next morning’s settlement report settles it for good.
   6. The answer is approved: the pending entry is posted, the hold is released, and current drops by $508.75. A decline would archive the entry and only release the hold. Either way it is one conditional transition out of pending, so a late callback and the poller cannot both apply it.
   7. The next morning, the network’s settlement report and the bank statement are matched against the push-to-card clearing account. The network settles the day’s pushes from our settlement account the next business day, so treasury keeps that account funded for a long weekend of cash-outs, ~$400 M on our numbers. Once the settlement line posts (DR p2c_clearing, CR bank_fbo), p2c_clearing should hold only pushes that have not settled yet.
5. The daily close against the pooled accounts. The proof that no money was created or lost. Every account that faces the outside world is matched to an outside record as of one cutoff, and the books must show that cash at the banks covers what users are owed.
   1. At midnight Eastern the day closes; after a 15-minute grace for legs in flight, the job sums every shard’s postings as of the cutoff, on replicas. Entries are immutable and carry effective_at, so “everything effective before midnight” is a fixed set once the grace period has passed, whenever the job runs. Replicas keep the load off the primaries. A transfer whose leg 1 is before midnight and leg 2 after shows up as transit balance, which is exactly money in flight.
   2. Internal checks: every entry balances, every cached balance equals its postings, and transit across shards equals the legs that were in flight. Only accounts touched today are re-summed, about 15 M: in one snapshot of each shard, yesterday’s verified balance plus the postings since must equal the row. A mismatch freezes that account’s outflows and opens a case, because it means some code path changed a balance without an entry.
   3. The partner banks’ prior-day statements for the pooled accounts arrive: ACH batch settlements, returns, wires, and the card network’s net settlement. Banks see only aggregates: one line per ACH batch, one for the network’s daily settlement. The detail behind each line comes from our own files and from the return and settlement files, which is why every entry stores the external reference it will be matched on.
   4. Line matching: ACH batches by file and batch id, returns by trace number, card charges and pushes by network reference, about 7 M records a day. Every record lands in one bucket: matched, timing (ours, settling tomorrow), or unexplained. Each clearing account (ach_receivable, ach_payable, p2c_clearing, card_receivable) must equal its open timing items exactly. The job takes minutes; the cost is investigating breaks, not the volume.
   5. The invariant: the ledger’s pooled-account balances equal the statements to the cent, and pooled cash covers every positive user balance. Because every entry balances, once every outward-facing account matches its outside record, the sum of user balances equals cash held plus receivables in flight minus payables in flight, by arithmetic. Treasury tops the pooled accounts up with company money to cover credit we have extended, because negative balances are receivables, not offsets: the coverage test money transmitter rules care about is cash against the sum of positive balances.
   6. Breaks become cases with both sides’ evidence; a correction is a new entry approved by two people, and the affected accounts’ outflows are held meanwhile. Recon never posts a plug to make the numbers tie: an unexplained credit is still somebody’s money until we know whose. A timing item older than three business days becomes a break. The break count, its dollar value and the oldest open item are the first numbers finance reads each morning.

Deep dives

The theory behind it

• Double-entry ledger: an interactive playground. Record four money transfers as balance updates and as double-entry journal entries, add a retried request and a crash mid-transfer, and see which approach loses or duplicates money.
• Digital wallets and stored balances: Designing wallets that hold money or credits: balances derived from a double-entry ledger, top-ups and withdrawals, peer-to-peer transfers, holds and authorisations, concurrency on hot balances, limits and KYC, multi-currency, reconciliation with banks, and in-app credits and virtual currencies.
• Money in system design: ledgers, idempotency and reconciliation: How to handle money correctly: integer minor units, double-entry ledgers, balances derived from entries, idempotent payment calls, the unknown-outcome state, authorisation and capture, and daily reconciliation with providers.
• Real-time fraud detection: Designing fraud and risk systems for payments and marketplaces: the decision point and latency budget, rules plus machine learning, real-time velocity features, device and network signals, graph features, step-up actions, review queues, feedback and label delay, and measuring precision and losses.

Related

• Design a Payment System
• Design a Distributed Cache
• Design a Real-Time Leaderboard
• Design AWS Step Functions
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit