Package tracking

The brief

You run the tracking page for a parcel company. People refresh it again and again while they wait for a delivery, and depots send a scan every time a parcel moves. Keep the page fast, lose at most the last minute of scans in a failure (scanners keep a copy and can resend), and make sure a broken text-message service cannot slow anything down.

Think of parcel tracking like UPS.

Users, scale and requirements

Who uses it

20 million people a month (approx.)

Audience in plain numbers

20,000,000 people per month

Normal peak

≈ 3,000 requests per second

Request mix

Read: 90%; Write: 7%; Notification: 3%

Speed for 99 of 100 requests

Read: ≈ 800 ms; Write: ≈ 1,100 ms

Successful requests

99.9%

Data safety

At most 1 minute of writes may be lost.

Monthly budget

≈ $16,000

Data at rest

≈ 5 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Read: 900 seconds; Write: 3,600 seconds; Notification: 900 seconds

Minimum retained history

90 days on authoritative stores

Personal reads

20% of reads are private; a shared public copy cannot answer them.

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

• About 15 million parcels a day, 8 scans each, about 0.5 KB per scan: roughly 60 GB a day, 90 days kept hot (approx.).
• Reads are tracking-page lookups, writes are depot scans, notifications are text and push alerts.
• The peak is a holiday-season evening. All numbers are rough approximations.
• Scored data retention: at least 90 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.
• 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

Do tracking answers have to be up to the second?

No. A status that is up to a minute old is fine. People care that the page opens fast and the next step is right.

Can a depot scan be lost or counted twice?

At most the last minute of scans, and only in a failure: scanners keep a copy and resend when the network drops, so the same scan can arrive twice. Counting it twice would show the wrong history.

What happens when the text-message service is down?

Alerts can arrive later. The tracking page must keep working and no alert may be dropped.

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. 10:15 · Dependency outage

   An outside service fails calls during an outage.

   Failed calls: 100%. Duration: ≈ 1,200 seconds.

2. 18:30 · Viral spike

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

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

What a strong design has to handle

• Most of the load is people checking the same parcel again and again. What could remember an answer for a minute?
• A 60 second cache means a status can be a minute old. For parcels that is fine; for a stock price it would not be.
• Collapsing misses protects the database when the cache is cold, at the price of a few people waiting for one shared refill.

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

• Remembering answers
• Waiting instead of breaking