Video streaming

The brief

You run a movie and series service for a growing audience. Each viewer pulls a few seconds of video at a time for two hours straight. Bandwidth is the largest cost by far, and everyone wants to start watching in the evening.

Think of a video service like Netflix.

Users, scale and requirements

Who uses it

400 thousand subscribers

Audience in plain numbers

400,000 users or devices

Normal peak

≈ 600 requests per second

Request mix

Stream chunk: 80%; Read: 10%; Search: 4%; Sign-in: 2%; Analytics event: 4%

Speed for 99 of 100 requests

Stream chunk: ≈ 1,000 ms; Read: ≈ 300 ms; Search: ≈ 400 ms; Sign-in: ≈ 1,000 ms

Successful requests

99.9%

Data safety

At most 1 minute of writes may be lost.

Monthly budget

≈ $108,000

Data at rest

≈ 250 TB

Where users are

North America: 60%; Europe: 30%; Asia Pacific: 10%

Home region

North America

Waiting deadlines

Stream chunk: 900 seconds; Read: 900 seconds; Search: 900 seconds; Sign-in: 900 seconds; Analytics event: 3,600 seconds

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

• Each viewer fetches one 2 MB chunk every 4 seconds.
• Bandwidth is priced per gigabyte sent to viewers (about 4 cents at list price, approx.).

Questions that shape the design

Is most of the library watched equally?

No. A few hundred titles get most of the viewing. The long tail is watched rarely.

How long can a viewer wait for the picture to start?

About a second for each chunk. More than that and the picture freezes.

Do viewers need to be signed in?

Yes. A subscription check happens once at the start, not for every chunk.

What if a new season launches?

A huge crowd presses play on the same episode in the same hour. It is the busiest night of the quarter.

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. 19:00 · Flash crowd

   A scheduled launch brings a sudden rush of requests.

   Traffic reaches 8 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds.

2. 12:00 · Cache stampede

   The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.

   Recovery window: ≈ 300 seconds.

3. 21:00 · Cost blowout

   A crawler hits uncached pages all day, and every pay-per-use part of the bill multiplies.

   Traffic for Read, Search reaches 1.5 times the scheduled load; rises over 600 seconds, holds for 21,600 seconds and eases over 600 seconds. Other request types keep their scheduled load. Billed usage multiplier: 3. Duration: ≈ 21,600 seconds.

What a strong design has to handle

• A few titles get most of the views. How can you use that to protect your storage and your bill?
• Deliver versioned video segments while bounding cold-origin load and startup delay.
• Every extra copy layer (edge, shield, storage) lowers your storage load, but each one adds a little delay for a rare title nobody has watched yet.
• Serving fewer quality levels shrinks the bill but makes the picture worse on a fast connection.

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 near users
• Where the money goes
• Hot, warm, cold and archive