Telehealth video visits

The brief

Patients join a video visit with a doctor from their phone. Most calls go straight between the two people, but the platform runs the waiting room, chat, sign-in, the join link and a relay for the calls that cannot connect directly. A bad minute here means a patient staring at a spinner.

Think of a video doctor visit.

Users, scale and requirements

Who uses it

800,000 visits a month (approx.)

Audience in plain numbers

600,000 people per month

Normal peak

≈ 3,000 requests per second

Request mix

Message: 38%; Read: 25%; Sign-in: 12%; Write: 8%; Notification: 6%; Upload: 5%; Search: 4%; Live segment: 2%

Speed for 99 of 100 requests

Message: ≈ 700 ms; Read: ≈ 700 ms; Sign-in: ≈ 1,000 ms; Write: ≈ 700 ms; Upload: ≈ 3,000 ms; Search: ≈ 500 ms; Live segment: ≈ 800 ms

Successful requests

99.8%

Data safety

At most 1 minute of writes may be lost.

Monthly budget

≈ $24,000

Data at rest

≈ 8 TB

Where users are

North America: 80%; Europe: 20%

Home region

North America

Waiting deadlines

Message: 900 seconds; Read: 900 seconds; Sign-in: 900 seconds; Write: 3,600 seconds; Notification: 900 seconds; Upload: 3,600 seconds; Search: 900 seconds; Live segment: 900 seconds

Personal reads

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

Required proofs

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.

• Messages include chat, presence in the waiting room and the signalling that sets up each call.
• Photos are patient uploads such as a rash; they are small.
• 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

Does the platform carry the video itself?

Only for about 1 call in 7. Most calls connect directly. The game shows that share as a small number of heavy media requests going through a relay.

What happens at the top of the hour?

Many visits start at :00 and :30, so sign-ins and waiting-room messages spike together, about 3 times the normal level for a minute.

How do patients find out the visit is ready?

A text or email with a join link, sent through outside providers.

Where are the patients?

Eight in ten are in North America, two in ten in Europe.

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. 09:00 · Synchronized rush

   Many callers send requests together instead of spreading them over time.

   Traffic for Sign-in, Message, Read, Sync change reaches 3 times the scheduled load; rises over 10 seconds, holds for 90 seconds and eases over 300 seconds. Other request types keep their scheduled load.

2. 10:15 · Zone outage

   An availability zone loses power or network access.

   Duration: ≈ 1,800 seconds.

3. 14:00 · Dependency outage

   An outside service fails calls during an outage.

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

What a strong design has to handle

• Messages are the biggest slice, and they need a live, two-way connection. Which element holds those open?
• Authorize a visit and recover media setup without conflating it with signaling.
• Direct calls between two phones cost the platform almost nothing; relaying every call would multiply the media bill, so the relay only serves calls that need it.
• Three zones with spare units cost about a third more than needed on a normal day and keep the visit alive when a building goes dark.

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

• Live sockets and presence
• Surviving a region