Skip to content
System Designer

Medium · Finance and payments

Peer-to-peer wallet

People split dinner by sending each other money from their phones. A transfer takes money from one balance and adds it to another, and the sender must see the new balance right away. A flaky mobile connection often makes the app send the same transfer twice. Practise this medium system design problem for free with a Google or GitHub account.

The brief

People split dinner by sending each other money from their phones. A transfer takes money from one balance and adds it to another, and the sender must see the new balance right away. A flaky mobile connection often makes the app send the same transfer twice.

Think of a wallet app like Venmo.

Users, scale and requirements

Who uses it
600,000 active people a month
Audience in plain numbers
600,000 people per month
Normal peak
≈ 2,500 requests per second
Request mix
Read: 50%; Payment: 20%; Sign-in: 10%; Write: 10%; Notification: 10%
Speed for 99 of 100 requests
Read: ≈ 700 ms; Payment: ≈ 800 ms; Sign-in: ≈ 1,000 ms; Write: ≈ 700 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $9,800
Data at rest
≈ 3 TB
Where users are
North America: 100%
Home region
North America
Waiting deadlines
Read: 900 seconds; Payment: 3,600 seconds; Sign-in: 900 seconds; Write: 3,600 seconds; Notification: 900 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
90% of reads are private; a shared public copy cannot answer them.
Required proofs
Audit trail; Managed encryption keys; Signed-in access

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Money is counted in cents, never in decimals.
  • Transfers settle between balances inside the wallet.
  • Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.

Questions that shape the design

Can a balance ever be wrong, even for a second?

The sender must always see their own latest balance. Other people can wait a moment.

What if the phone loses signal after tapping Send?

The app retries with the same transfer key. The money must move once.

What does a regulator ask for?

A tamper-proof record of every transfer, encryption, and proof that every action was a signed-in user.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 12:00 · Duplicate delivery

    The queue redelivers messages. Without duplicate protection, side effects may be applied twice.

    Affected share: 1%. Duration: ≈ 3,600 seconds.

  2. 16:00 · Compliance audit

    An auditor checks your design: who did what, encryption keys, personal data, backups and consent.

  3. 20:30 · Database failover

    The primary database dies. Recovery depends on the standby and failover settings.

    Duration: ≈ 60 seconds.

What a strong design has to handle

  • A reader may use a copy that is a moment behind. Which reads in this app must never do that?
  • Conserve funds with atomic, unique transfers under concurrent spending.
  • No cache on balances means every balance read hits the ledger. It costs more database and avoids ever showing a stale balance after a transfer.
  • Sync replication adds a few milliseconds to each transfer and guarantees a failover loses nothing. Async would be faster and could drop the last second of transfers.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems