System Design

Peer-to-Peer Payments

Design a peer-to-peer money transfer app like Venmo or Cash App.

Functional requirements

• Users can send money to another user by phone number or username, and the recipient sees the funds in their balance within seconds.
• A send is funded from the sender's balance first and, if the balance is short, by pulling the remainder from the sender's linked bank account (e.g., $40 from balance plus $60 from Chase); the recipient can use the funds right away even though the bank pull settles later.
• Users can request money from another user, who can accept (triggering a normal send back) or decline.
• Users can view their balance and a history of sends, receipts, and bank pulls with a status (pending, completed, failed, or reversed).
• Per-user sending limits are enforced (e.g., $3,000 per rolling 7 days for verified users, $300 for unverified), and a send that would exceed the limit is rejected.

Non-functional requirements

• A transfer is atomic: the sender is debited and the recipient credited together or not at all, and a send is applied exactly once under client retries, double taps, or two devices.
• p99 under 500ms end to end for a balance-funded send; a bank-funded send may take up to 3s to be accepted, and its settlement is asynchronous.
• Correctness over availability for balances: no balance may go negative through concurrent sends, and the system rejects a send during a partition rather than risk a double spend; history and the recipient's notification may lag by a few seconds.
• Durability: every acknowledged transfer and bank pull is persisted before the user is told it succeeded, and records are retained for 7 years.
• Bank pulls that fail or reverse after the recipient was credited must be detected and recovered (the platform absorbs or collects the loss); bank credentials live with a third-party aggregator, never in this system.

Scaling & constraints

• 80M registered users, 25M monthly active; ~3,000 sends per second at peak (Friday evenings, rent day on the 1st), ~500/sec average.
• Read:write ratio of roughly 15:1 (balance and history reads vs. sends, requests, and bank pulls).
• Each transfer record is ~500 bytes; ~1.3B transfers per month, retained for 7 years, growing ~35% per year.
• About 40% of sends need a bank pull for some or all of the amount; the bank rail acknowledges a pull in 1-3s but settles in 1-3 business days, ~2% of pulls fail after acknowledgment (insufficient funds, closed account), and ~0.3% are reversed weeks later (unauthorized transaction claims).
• Hot spots: a small number of accounts (landlords, group organizers, small businesses collecting by username) receive up to 50 sends per second each around rent day, while the median user makes 4 transfers per month.
• At any moment roughly $400M of recipient-credited but bank-unsettled funds are outstanding; a single user can have up to 5 unsettled pulls at once.

Out of scope

• Social feed, comments, and contact discovery.
• Bank account linking, identity verification, and the bank aggregator integration itself.
• Cash-out to bank, debit card issuing, and merchant payments.
• Fraud and risk scoring beyond the stated per-user limits.