Skip to content
System Designer

Hard · Finance and payments

Crypto exchange

People trade coins, check prices and withdraw funds around the clock from every continent. A sudden price crash makes everyone log in and trade at once, attackers flood you hoping to knock the site over, and a leaked key could empty a wallet. Balances must never be wrong. Practise this hard system design problem for free with a Google or GitHub account.

The brief

People trade coins, check prices and withdraw funds around the clock from every continent. A sudden price crash makes everyone log in and trade at once, attackers flood you hoping to knock the site over, and a leaked key could empty a wallet. Balances must never be wrong.

Think of a crypto exchange like Coinbase.

Users, scale and requirements

Who uses it
3 million traders, 300,000 active in a month
Audience in plain numbers
300,000 people per month
Normal peak
≈ 6,000 requests per second
Request mix
Read: 50%; Write: 25%; Payment: 5%; Sign-in: 15%; Report: 5%
Speed for 99 of 100 requests
Read: ≈ 700 ms; Write: ≈ 700 ms; Payment: ≈ 1,500 ms; Sign-in: ≈ 1,000 ms; Report: ≈ 5,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $32,000
Data at rest
≈ 5 TB
Where users are
North America: 40%; Europe: 30%; Asia Pacific: 30%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds; Sign-in: 900 seconds; Report: 3,600 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
50% 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.

  • A "payment" is a deposit or a withdrawal.
  • Orders are the writes.

Questions that shape the design

Is the exchange open all day?

Yes. There is no closing bell, and traffic follows the sun across regions.

What is the most dangerous mistake?

A key that signs withdrawals getting out. Keys live in a key service and can be rotated in minutes.

Can prices be a little stale?

A price on a screen can be a few seconds old. A balance cannot.

What does the regulator want?

An audit trail, encryption with managed keys, and every staff and user action tied to a signed-in identity.

The traffic day

Traffic following users around the world. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 13:00 · DDoS attack

    A botnet floods the system with junk requests.

    Extra attack traffic is 15 times the configured peak. Duration: ≈ 1,800 seconds.

  2. 16:00 · Flash crowd

    A scheduled launch brings a sudden rush of requests.

    Traffic for Read, Write, Sign-in reaches 4 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds. Other request types keep their scheduled load.

  3. 21:00 · Leaked key

    An API key is pushed to a public repo. It must be rotated now.

    Restart window: ≈ 1,200 seconds.

What a strong design has to handle

  • The attack and the price crash both send far more than your servers can take. What can answer or reject traffic before it reaches them?
  • Reserve balances before matching and serialize financial settlement.
  • The DDoS shield costs about $3,000 a month whether or not you are attacked. It is insurance, and without it a single attack can end the day.
  • A 5 second edge cache makes prices slightly stale and cuts origin reads by about 90 percent. Balances are never cached.

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