Easy · IoT and devices
EV charging network
Thousands of chargers report their status every few seconds and send a record when a session ends. Drivers open an app to find a free charger. A session record must never be lost or counted twice, because it becomes a bill. Practise this easy system design problem for free with a Google or GitHub account.
The brief
Thousands of chargers report their status every few seconds and send a record when a session ends. Drivers open an app to find a free charger. A session record must never be lost or counted twice, because it becomes a bill.
Think of a public charger network.
Users, scale and requirements
- Who uses it
- 2 million drivers a month (approx.)
- Audience in plain numbers
- 2,000,000 people per month
- Normal peak
- ≈ 1,800 requests per second
- Request mix
- Telemetry batch: 65%; Read: 22%; Analytics event: 6%; Write: 5%; Sign-in: 2%
- Speed for 99 of 100 requests
- Read: ≈ 600 ms; Write: ≈ 600 ms; Sign-in: ≈ 1,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $4,500
- Data at rest
- ≈ 1 TB
- Where users are
- North America: 70%; Europe: 30%
- Home region
- North America
- Waiting deadlines
- Telemetry batch: 3,600 seconds; Read: 900 seconds; Analytics event: 3,600 seconds; Write: 3,600 seconds; Sign-in: 900 seconds
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- About 20,000 chargers, each sending a status every 10 to 20 seconds (approx.).
- A session record is about 1 KB (approx.).
- All numbers are rough approximations.
Questions that shape the design
Must the status on the map be exact?
No. Ten seconds behind is fine. Drivers just need to know a charger is probably free.
Can a charger retry a session record?
Yes, and it will after any bad connection. A retry must not bill the driver twice.
Can billing finish later?
Yes. A bill can be settled in the background, as long as no record is lost.
The traffic day
Morning and evening commute peaks. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
17:30 · Dependency outage
An outside service fails calls during an outage.
Failed calls: 100%. Duration: ≈ 1,200 seconds.
08:00 · Synchronized rush
Many callers send requests together instead of spreading them over time.
Traffic for Telemetry batch reaches 4 times the scheduled load; rises over 10 seconds, holds for 60 seconds and eases over 300 seconds. Other request types keep their scheduled load.
What a strong design has to handle
- A charger will retry after a bad connection. What stops a retry from billing twice?
- Keeping only the latest status per charger makes writes cheap. History, if wanted, goes to a separate cheaper store.
- The idempotency store costs a lookup per record, and it is what makes retries safe.
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
- Medium
Notification service
Every other team asks you to send messages: order shipped, new login, a sale starting. You send them by push, email and text through outside providers who have their own limits. Send each message once, and never block the team that asked.
- Hard
Scheduled job service
Customers register jobs: "call my web address every night at 02:00" or "every hour on the hour". Aim to fire within 5 seconds; work still waiting after 60 seconds counts as failed. Retry safely after a crash. One external effect requires the customer endpoint to honor a stable job occurrence key. Half the world picks the top of the hour, so a huge crowd of jobs comes due in the same second.
- Hard
Video upload pipeline
Creators upload videos that must be converted into several qualities before anyone can watch. Conversion is slow, costs real money per video, and the converter sometimes fails on a broken file. Nothing a creator uploads can be lost.
- Easy
Invoicing and billing
Small businesses create invoices, email them to customers and take card payments online. On the last working day of the month everyone sends and chases invoices at once. Nobody may get the same invoice email twice, and no invoice may vanish.