Skip to content
System Designer

Medium · Mobility and logistics

Food delivery

You run food delivery in a few big cities. People browse menus, pay for an order, and watch a courier move on a map. Dinner time is brutal, and the payment company sometimes slows down. Nobody may be charged twice, and no paid order may vanish. Practise this medium system design problem for free with a Google or GitHub account.

The brief

You run food delivery in a few big cities. People browse menus, pay for an order, and watch a courier move on a map. Dinner time is brutal, and the payment company sometimes slows down. Nobody may be charged twice, and no paid order may vanish.

Think of an app like DoorDash.

Users, scale and requirements

Who uses it
8 million people a month (approx.)
Audience in plain numbers
8,000,000 people per month
Normal peak
≈ 5,000 requests per second
Request mix
Read: 50%; Search: 15%; Payment: 4%; Write: 3%; Location ping: 26%; Notification: 2%
Speed for 99 of 100 requests
Read: ≈ 300 ms; Search: ≈ 300 ms; Payment: ≈ 2,500 ms; Write: ≈ 300 ms
Successful requests
99.5%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $15,000
Data at rest
≈ 2 TB
Where users are
North America: 100%
Home region
North America
Waiting deadlines
Read: 900 seconds; Search: 900 seconds; Payment: 3,600 seconds; Write: 3,600 seconds; Location ping: 900 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
50% of reads are private; a shared public copy cannot answer them.
Required proofs
Managed encryption keys; Audit trail

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

  • Use the payment share to estimate order rate. Card data stays with the payment company.
  • Dinner peak is about 5,000 requests a second. Courier pings are 26 percent of traffic (approx.).
  • All numbers are rough approximations.
  • 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

How fresh must the courier dot on the map be?

Within a few seconds. Couriers send a position every 4 to 5 seconds.

What if the payment company is slow?

Orders still need to be taken. Tell the customer the payment is pending and finish it when the service is back.

Can a customer see an old order status after paying?

No. Right after placing an order the customer must see it.

The traffic day

Lunch and evening meal peaks. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 12:00 · Viral spike

    A post blows up. Traffic climbs to several times normal within minutes.

    Traffic reaches 2.5 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.

  2. 18:30 · Slow dependency

    An outside service slows down. Your servers fill with requests waiting on it.

    Added response time: ≈ 3,000 ms. Duration: ≈ 1,800 seconds.

  3. 19:15 · Duplicate delivery

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

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

What a strong design has to handle

  • A payment company that slows to 3 seconds will fill your servers with waiting requests. What can stop that?
  • Coordinate a paid order and restaurant acceptance without duplicate external effects.
  • A 1 second payment timeout fails some slow-but-fine payments. In exchange your servers keep serving menus during a payment slowdown.
  • Sync replication on the order database costs a few milliseconds per write and means a failover loses nothing.

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