Pharmacy stock and refills

The brief

A pharmacy chain with 4,000 stores tracks how many boxes of each medicine every store has, takes refill requests, and shows patients which nearby store has their medicine today. If the system says a store has a box that is gone, a patient makes a wasted trip.

Think of a pharmacy chain's stock and refill system.

Users, scale and requirements

Who uses it

9 million patients, 4,000 stores (approx.)

Audience in plain numbers

9,000,000 users or devices

Normal peak

≈ 2,500 requests per second

Request mix

Read: 33%; Search: 25%; Write: 20%; Analytics event: 10%; Notification: 5%; Sign-in: 4%; Report: 3%

Speed for 99 of 100 requests

Read: ≈ 300 ms; Search: ≈ 400 ms; Write: ≈ 300 ms; Sign-in: ≈ 1,000 ms; Report: ≈ 10,000 ms

Successful requests

99.9%

Data safety

No acknowledged write may be lost.

Monthly budget

≈ $130,000

Data at rest

≈ 5 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Read: 900 seconds; Search: 900 seconds; Write: 3,600 seconds; Analytics event: 3,600 seconds; Notification: 60 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

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

Required proofs

Audit trail; Signed-in access; Managed encryption keys

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

• Each store sends a stock event every time a box is scanned in or out.
• A "write" here is a dispense or a refill order.
• 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 wrong may a stock count be?

For browsing, a few seconds late is fine. For handing out a controlled medicine, the count must be exact at the moment of sale.

Is there a nightly report?

Yes. Head office runs big stock reports during the night and again in the morning. They are heavy.

Is one medicine ever far more popular than others?

Yes. A flu season or a shortage can make one product ID hold a third of all lookups.

Are patients told when a refill is ready?

Yes, by push or text. It can arrive a minute late, but not twice.

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.

1. 07:30 · Noisy neighbour

   A competing workload reduces the capacity available to the live service.

   Available capacity multiplier: 0.4. Duration: ≈ 2,400 seconds.

2. 11:00 · Replication lag

   Copies fall behind. Users read old data, even their own fresh changes.

   Copy lag: ≈ 45 seconds. Duration: ≈ 1,200 seconds.

3. 17:00 · Hot key

   One item gets a huge share of traffic: a celebrity profile, one product, one merchant.

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

What a strong design has to handle

• Which requests must be exact, and which can be a little behind? Send the first to the main copy and the second to a copy.
• Distinguish stale stock discovery from authoritative reservation.
• The search index can be a few seconds behind. That is fine for "who has it nearby", and the till still checks the exact count before dispensing.
• Reports in a warehouse cost another $1,800 a month and take the heavy job off the live database; running them on the main database is free until a morning where it is not.

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

• Copies are a little behind
• Search is a copy