Easy · Productivity
Calendar and invites
People view their week, create meetings and invite others. Each invite sends an email or phone alert. Monday at 9 am everyone opens the calendar at once. A repeated send must never produce two invites, and a slow email partner must not slow the calendar. Practise this easy system design problem for free with a Google or GitHub account.
The brief
People view their week, create meetings and invite others. Each invite sends an email or phone alert. Monday at 9 am everyone opens the calendar at once. A repeated send must never produce two invites, and a slow email partner must not slow the calendar.
Think of a shared calendar.
Users, scale and requirements
- Who uses it
- 10 million people a month (approx.)
- Audience in plain numbers
- 10,000,000 people per month
- Normal peak
- ≈ 1,200 requests per second
- Request mix
- Read: 79%; Write: 12%; Notification: 3%; Sign-in: 6%
- Speed for 99 of 100 requests
- Read: ≈ 400 ms; Write: ≈ 400 ms; Sign-in: ≈ 1,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $7,100
- Data at rest
- ≈ 0.5 TB
- Where users are
- North America: 60%; Europe: 40%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds; Notification: 60 seconds; Sign-in: 900 seconds
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- About 144 new meetings a second at the Monday peak (approx.).
- On a busy morning the email partner slows to a few dozen messages a second (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
Must an alert arrive instantly?
Within a minute is fine. The calendar page itself must be quick.
What if the email partner limits us?
It will, at busy times. Alerts wait in a line and go out when the partner allows.
What if a message is delivered twice?
The guest must still see one invite, so each invite carries a unique key.
The traffic day
Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
09:00 · Provider rate limit
An outside service lowers its configured request quota and answers 'too many requests' above the reduced limit.
Provider capacity falls to 40% of its configured quota. Duration: ≈ 1,200 seconds.
13:00 · Duplicate delivery
The queue redelivers messages. Without duplicate protection, side effects may be applied twice.
Affected share: 5%. Duration: ≈ 3,600 seconds.
What a strong design has to handle
- The email partner slows down at 9 am. Where do the extra alerts wait?
- A short cache time keeps the week view fresh. A long one saves the database but shows a stale meeting.
- A queue means an alert may be a minute late. That is the price of never blocking the calendar.
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.